Reactions to crysis movies on gametrailers
by Phil Carlisle · in Torque Game Engine Advanced · 03/21/2007 (2:57 am) · 44 replies
I was watching the movies of the crysis toolset on gametrailers.com today. Thinking about the technology they have in there and really trying to figure out how TSEA would get to somewhere near that point.
Trailer One
Trailer Two
There are a few things that struck me as interesting:
1) Day and night cycle with shadows. - This is interesting because EVERYTHING is shadowed so clearly they have some method of allocating shadow buffer space thats quite effective. The shadows seem to allow transparency at least at the on/off level. The shadows are all seemingly realtime updated too. Although I saw some artifacting in far off viewpoints when he moved the camera quickly (to be expected).
2) Foliage editing - this one seems like a reasonbly simple thing, but he could place trees and larger foliage items by simple clicking on the ground, this would be a really simple feature to add to TSEA's toolchain and would make planting things much quicker I think.
3) Foliage generation - in one part, he shows the procedural foliage as well. This is based on terrain material and coverage values. So as you edit the terrain base coverage map, the foliage updates realtime too. So clearly we can discern that there is a single foliage coverage manager that reads the coverage map and distrubutes foliage appropriately (plus, allows batching and all that render stuff).
4) The usual terrain texture painting tools... natch.
5) An interesting sort of integration of voxel editing. Actually, we did that in worms 3d a few years back and it works really quite well. Basically its a simple marching cubes algo based around some volume elements. His sort of editing thing was quite nice (a ball that either adds or subtracts space). Dunno how they do the texture selection for it, plus there were some lighting issues inside the chunk he hollowed out.
6) When looking at the second video, there is ambient occlusion which seems (might be wrong) to be baked into interiors and other objects. Perhaps an ambient occlusion map for each object?
7) He showed a nice system that did visibility culling, basically it looks like its based off the "large occluders" technique (cant remember the paper thats in, but its well known), similar to the technique they use in that visibility culler thing the guys from sur-render did, goddam I cant remember ANYTHING!!).
8) Interesting simple camera path animator thingy with scrubbable timeline.
9) AI Actor class, with some kind of link indirection to the character, he called it "archetype", but yeah, basically datablock.. meh, datablocks.
So takeaways from it are:
1) Day/Night with "always on" shadows would be do-able. I dont really like the fact that shadows have to be tweaked so much right now. It seems like we should just have global options for shadows and leave it at that. Clearly it has implications, might mean models need a shadow geometry too?
2) Foliage placement by clicking on the heightmap - relatively easy to throw into TSEA as it is.
3) Foliage generation - Again relatively easy, would need to sample the map material and place foliage dependant upon it. if we relax the requirement that this needs to be editable ONLINE then I think it'd work fine.
4) Natch
5) This would require a fair bit of work to integrate, but the actual implementation is relatively well understood (marching cubes), it adds the opportunity for overhangs and caves without then requiring an editable mesh toolset, which means atlas for instance could go back to being a heightfield, which would simplify the toolset issues for atlas.
6) Ambient occlusion map, seems like it'd be easy to do a baked one, but I'd rather back in the engine with some regeneration step.
7) Interesting problem, but it feels like TSEA could use something here. Complexity wise, dunno, but its a well known issue and has had lots of academic research applied.
8) Pretty easy, Ben sorta prototyped something similar a good while back.
9) Again, pretty easy, main issue is updated pathing, no idea if they did that, didnt see any path gen tools in the demo's. Maybe once they release the game we can see how it works.
One of the interesting things really is the uniformity of things. I.e. uniform lighting, tools, access to parameters etc. Which kind of makes me thing that some kind of property system with variable reflection and interrogation would need to be in place before this system would really work. For instance, a script being able to access ANY VISIBLE PROPERTY of any other game object would seem to be required. Kind of like the properties editor, but a bit more robust and automatic. I.e. non crashy range checked and interrogation based.
Basically I think Cryengine 2 is kind of similar in mindset to the functionality that the original Tribes gameplay required, so its useful to compare the feature set (I can imagine trying to create Crysis using the T2 engine 10 years ago for example).
What say you? am I wrong?
Trailer One
Trailer Two
There are a few things that struck me as interesting:
1) Day and night cycle with shadows. - This is interesting because EVERYTHING is shadowed so clearly they have some method of allocating shadow buffer space thats quite effective. The shadows seem to allow transparency at least at the on/off level. The shadows are all seemingly realtime updated too. Although I saw some artifacting in far off viewpoints when he moved the camera quickly (to be expected).
2) Foliage editing - this one seems like a reasonbly simple thing, but he could place trees and larger foliage items by simple clicking on the ground, this would be a really simple feature to add to TSEA's toolchain and would make planting things much quicker I think.
3) Foliage generation - in one part, he shows the procedural foliage as well. This is based on terrain material and coverage values. So as you edit the terrain base coverage map, the foliage updates realtime too. So clearly we can discern that there is a single foliage coverage manager that reads the coverage map and distrubutes foliage appropriately (plus, allows batching and all that render stuff).
4) The usual terrain texture painting tools... natch.
5) An interesting sort of integration of voxel editing. Actually, we did that in worms 3d a few years back and it works really quite well. Basically its a simple marching cubes algo based around some volume elements. His sort of editing thing was quite nice (a ball that either adds or subtracts space). Dunno how they do the texture selection for it, plus there were some lighting issues inside the chunk he hollowed out.
6) When looking at the second video, there is ambient occlusion which seems (might be wrong) to be baked into interiors and other objects. Perhaps an ambient occlusion map for each object?
7) He showed a nice system that did visibility culling, basically it looks like its based off the "large occluders" technique (cant remember the paper thats in, but its well known), similar to the technique they use in that visibility culler thing the guys from sur-render did, goddam I cant remember ANYTHING!!).
8) Interesting simple camera path animator thingy with scrubbable timeline.
9) AI Actor class, with some kind of link indirection to the character, he called it "archetype", but yeah, basically datablock.. meh, datablocks.
So takeaways from it are:
1) Day/Night with "always on" shadows would be do-able. I dont really like the fact that shadows have to be tweaked so much right now. It seems like we should just have global options for shadows and leave it at that. Clearly it has implications, might mean models need a shadow geometry too?
2) Foliage placement by clicking on the heightmap - relatively easy to throw into TSEA as it is.
3) Foliage generation - Again relatively easy, would need to sample the map material and place foliage dependant upon it. if we relax the requirement that this needs to be editable ONLINE then I think it'd work fine.
4) Natch
5) This would require a fair bit of work to integrate, but the actual implementation is relatively well understood (marching cubes), it adds the opportunity for overhangs and caves without then requiring an editable mesh toolset, which means atlas for instance could go back to being a heightfield, which would simplify the toolset issues for atlas.
6) Ambient occlusion map, seems like it'd be easy to do a baked one, but I'd rather back in the engine with some regeneration step.
7) Interesting problem, but it feels like TSEA could use something here. Complexity wise, dunno, but its a well known issue and has had lots of academic research applied.
8) Pretty easy, Ben sorta prototyped something similar a good while back.
9) Again, pretty easy, main issue is updated pathing, no idea if they did that, didnt see any path gen tools in the demo's. Maybe once they release the game we can see how it works.
One of the interesting things really is the uniformity of things. I.e. uniform lighting, tools, access to parameters etc. Which kind of makes me thing that some kind of property system with variable reflection and interrogation would need to be in place before this system would really work. For instance, a script being able to access ANY VISIBLE PROPERTY of any other game object would seem to be required. Kind of like the properties editor, but a bit more robust and automatic. I.e. non crashy range checked and interrogation based.
Basically I think Cryengine 2 is kind of similar in mindset to the functionality that the original Tribes gameplay required, so its useful to compare the feature set (I can imagine trying to create Crysis using the T2 engine 10 years ago for example).
What say you? am I wrong?
About the author
Recent Threads
#22
I would love to hear how people think the Atlas tools should work after seeing the Crysis method of using voxels. I don't know too much about the the implementation, though my experience with such things is none. I intended to do some reading, but I got wrapped up with other things.
I loved the entity snapping dealie they had going on. What other kind of features should be integrated into the mission editor? Snap to entity shouldn't be too hard, on bsp objects there could be a snap center to surface or something, that wouldn't be difficult at all.
About prefabs, they never specified if you could tool with them after their creation, maybe my memory's fuzzy. You could do it with some container system like the SimGroup, then switch up the editor so the dot is only rendered at the center of the Prefab, add a "break prefab" type function, and then it should be quite simple to create a prefab editor, and store it as a sort of datablock thing. Then its just a simple bit of work from there. I'm sure that with a large game there could get to be a large amount of prefabs, it would probably be faster to load the sets as needed, save memory (datablocks can get quite massive in memory allocation, how would this be avoided?)
Cheers
03/23/2007 (1:57 am)
It would be a shame to let this thread die, as its a very interesting read. I know that I've been reading it waiting for another response, though have to admit I was a bit scared of posting for fear of being eaten alive ;)I would love to hear how people think the Atlas tools should work after seeing the Crysis method of using voxels. I don't know too much about the the implementation, though my experience with such things is none. I intended to do some reading, but I got wrapped up with other things.
I loved the entity snapping dealie they had going on. What other kind of features should be integrated into the mission editor? Snap to entity shouldn't be too hard, on bsp objects there could be a snap center to surface or something, that wouldn't be difficult at all.
About prefabs, they never specified if you could tool with them after their creation, maybe my memory's fuzzy. You could do it with some container system like the SimGroup, then switch up the editor so the dot is only rendered at the center of the Prefab, add a "break prefab" type function, and then it should be quite simple to create a prefab editor, and store it as a sort of datablock thing. Then its just a simple bit of work from there. I'm sure that with a large game there could get to be a large amount of prefabs, it would probably be faster to load the sets as needed, save memory (datablocks can get quite massive in memory allocation, how would this be avoided?)
Cheers
#23
I'd go with some runtime data integrity checking and just pass checksums to authenticate content. So instead of passing datablocks, you require client and server agree on content checksums and load things locally. Anything that needs to be created on the fly does self-replication across the net and uses automatic reflection for networked parameters. Essentially I think that networking of objects should be as automated as possible.
Which actually comes down to the object model. Inheritance versus aggregation, objects vs components basically. I'm in favour of the latter and I know SOME at GG are the same, but havent heard whats progressing in that area.
In general, I think the toolset in game needs some examination mainly in the usability area. If you look at the TGB interface and compare it to the TGE interface, clearly you can see where the love has gone :)
We (militarygarage) have learnt to stay well within the limits of the current tech. Our experience with adding our own physics tech has taught us a lot in terms of reliance on technology (and perhaps more importantly the people we work with to create it). So this really isnt an issue for us beyond the "wouldnt it be interesting to have access to this" kind of thing.
In the end, I've got the feeling that we are far better of working with the machine than raging against it, but if we can help influence the machine all the better.
03/23/2007 (4:23 am)
To be honest, I think that datablocks are a hinderance rather than a benefit. Unless you absolutely HAVE to do some kind of first-time data delivery, I think datablocks are a poor method of defining things.I'd go with some runtime data integrity checking and just pass checksums to authenticate content. So instead of passing datablocks, you require client and server agree on content checksums and load things locally. Anything that needs to be created on the fly does self-replication across the net and uses automatic reflection for networked parameters. Essentially I think that networking of objects should be as automated as possible.
Which actually comes down to the object model. Inheritance versus aggregation, objects vs components basically. I'm in favour of the latter and I know SOME at GG are the same, but havent heard whats progressing in that area.
In general, I think the toolset in game needs some examination mainly in the usability area. If you look at the TGB interface and compare it to the TGE interface, clearly you can see where the love has gone :)
We (militarygarage) have learnt to stay well within the limits of the current tech. Our experience with adding our own physics tech has taught us a lot in terms of reliance on technology (and perhaps more importantly the people we work with to create it). So this really isnt an issue for us beyond the "wouldnt it be interesting to have access to this" kind of thing.
In the end, I've got the feeling that we are far better of working with the machine than raging against it, but if we can help influence the machine all the better.
#24
Phil, you really need to take some time and look at Torque X :)
It's 100% aggregation from the game developer's point of view.
03/23/2007 (10:06 am)
Quote:
Which actually comes down to the object model. Inheritance versus aggregation, objects vs components basically. I'm in favour of the latter and I know SOME at GG are the same, but havent heard whats progressing in that area
Phil, you really need to take some time and look at Torque X :)
It's 100% aggregation from the game developer's point of view.
#25
But we need a solution that is commercially viable, we need TGEAX or something. I know its a load of work, but at some point, we need to think forward and look at commercially viable platforms that are well architected and capable of matching modern requirements.
Torque is getting a bit creaky, with all the mods and patches and whatnot. TSEA is a good stepping stone, only I think its actually harmed somewhat by backwards compatability with TGE.
I absolutely buy into the component aggregation model, I just dont buy into C# so much and I buy into XNA with creators club even less (I'm not talking generally here, I'm talking specifically for my needs).
I'm not saying I have any expectations, what I'm saying is that we can discuss what the next generation looks like, specifically in terms of toolchains. I think Cryengine2 offers some good thinking in terms of the toolchain and if any development goes forward, it would be useful to think of the usability of the toolchain.
Rambling, I'll stop now :)
03/23/2007 (10:14 am)
Stephen: Yeah, I know. But X isnt commercially viable. I'm looking at it for the Uni over the summer, but right now I havent got the time.But we need a solution that is commercially viable, we need TGEAX or something. I know its a load of work, but at some point, we need to think forward and look at commercially viable platforms that are well architected and capable of matching modern requirements.
Torque is getting a bit creaky, with all the mods and patches and whatnot. TSEA is a good stepping stone, only I think its actually harmed somewhat by backwards compatability with TGE.
I absolutely buy into the component aggregation model, I just dont buy into C# so much and I buy into XNA with creators club even less (I'm not talking generally here, I'm talking specifically for my needs).
I'm not saying I have any expectations, what I'm saying is that we can discuss what the next generation looks like, specifically in terms of toolchains. I think Cryengine2 offers some good thinking in terms of the toolchain and if any development goes forward, it would be useful to think of the usability of the toolchain.
Rambling, I'll stop now :)
#26
03/23/2007 (11:23 am)
I'm just enjoying learning from this exchange. Now THIS is a forum thread! Damn! 
#27
03/23/2007 (12:31 pm)
Is it possible to frame a thread, and hang it on a wall? 
#28
03/23/2007 (2:30 pm)
I agree, this was an incredibly stimulating discussion to read. I like TGEA, I really do, and I think it has enormous potential. In most cases, the ease with which you can make top-quality graphics is really impressive. However, I think it suffers from some tool-chain problems (like has been mentioned here). Once I think those are addressed in a serious manner, there will be nothing that can beat it as a development platform.
#29
Over summer I should get some time to implement dynamic ambient occlusion maps, at least onto skinned objects.
I'm not big into tech so much right now, but I love playing with these things, so you never know if I dont try out a voxel/marching cubes implementation too.
I also want to hack the lighting kit to get rid of the interface, which for me is almost unusable (it might be a mental blockage or something, but I just cant get my head around lights not having thier own properties and relying on datablocks).
In fact, i think thats a bit problem for me overall, the loathing of everything having to have multiple parts (the original class AND a datablock) when clearly it breaks down the object model completely. I'd much rather have an object instance and per instance data setup. Automated reflection over the network would allow any per-instance changes to be replicated without having any extra code, so for example:
Light.colour = "1,1,1,1" would affect the colour attribute and that would replicate the same changes to any ghost instances.
So the colour attribute of the light object would be in some way bound to the light object AND be network replicated. It would have a dirty check on it, all classes would be able to implement network aware attributes which would silenty replicate themselves on alteration (I'm pretty sure I read an article about doing this in a MMOG design book I read, which I forget the name of).
There are plenty of API's which do something similar, one that springs to mind is replica.net, although I havent investigated that fully.
I'll maybe have a look at adding a project to our masters in games programming to see if any of my students bite on tackling that issue.
03/23/2007 (6:08 pm)
Ah, I remember who it was that did sur-render and the visibility stuff, it was my mate jouni at hybrid graphics, I believe they sold it as hybrid PVS or some such. It was used in star wars galaxies by SCEA.Over summer I should get some time to implement dynamic ambient occlusion maps, at least onto skinned objects.
I'm not big into tech so much right now, but I love playing with these things, so you never know if I dont try out a voxel/marching cubes implementation too.
I also want to hack the lighting kit to get rid of the interface, which for me is almost unusable (it might be a mental blockage or something, but I just cant get my head around lights not having thier own properties and relying on datablocks).
In fact, i think thats a bit problem for me overall, the loathing of everything having to have multiple parts (the original class AND a datablock) when clearly it breaks down the object model completely. I'd much rather have an object instance and per instance data setup. Automated reflection over the network would allow any per-instance changes to be replicated without having any extra code, so for example:
Light.colour = "1,1,1,1" would affect the colour attribute and that would replicate the same changes to any ghost instances.
So the colour attribute of the light object would be in some way bound to the light object AND be network replicated. It would have a dirty check on it, all classes would be able to implement network aware attributes which would silenty replicate themselves on alteration (I'm pretty sure I read an article about doing this in a MMOG design book I read, which I forget the name of).
There are plenty of API's which do something similar, one that springs to mind is replica.net, although I havent investigated that fully.
I'll maybe have a look at adding a project to our masters in games programming to see if any of my students bite on tackling that issue.
#30
About Number 2 in your original post.
There's code in the fxFoilage(/Shape)Replicator that places things onto the ground automatically (using ray cast per object). I had to remove this for my space game because it would not find the ground and then not place them at all . So that code right there could be used. It should be an Editor Setting though.
04/03/2007 (3:20 am)
Hehe... reading threads like these make me feel stupid (since I dont understand most of the tech).... Thats why I stay out of them.About Number 2 in your original post.
There's code in the fxFoilage(/Shape)Replicator that places things onto the ground automatically (using ray cast per object). I had to remove this for my space game because it would not find the ground and then not place them at all . So that code right there could be used. It should be an Editor Setting though.
#31
I just started reading this thread, so my response is a couple responses late but....
I am using aggregation for all of my game classes using a component model. To start, I took out shape base, created a base component, created a component holder, and then made the functional components (e.g. ModelComponent, EnergyComponent, DamageComponent, etc).
This has vastly simplified my game object code and allows for objects that are network efficient.
Let me know if you want to talk about this offline...
Todd
04/18/2007 (8:59 am)
Phil,I just started reading this thread, so my response is a couple responses late but....
I am using aggregation for all of my game classes using a component model. To start, I took out shape base, created a base component, created a component holder, and then made the functional components (e.g. ModelComponent, EnergyComponent, DamageComponent, etc).
This has vastly simplified my game object code and allows for objects that are network efficient.
Let me know if you want to talk about this offline...
Todd
#32
04/18/2007 (9:51 am)
@Todd - Did this solve the "running out of bitmasks" issues that you frequently run into when extending ShapeBase? How did you go about that?
#33
Well, Clarke did much the same thing about 3-4 years back. I bought into the aggregate model before then due to my experience with weapon class proliferation in W3D way back when.
I've really no clear picture why it hasnt been rolled into TGE/A, other than it would probably break a lot of existing hacks.
I guess what it boils down to is a core re-write of a lot of the TGE innards to better serve usability and modularity, outside of the hacking thats gone on for the last half dozen years. Now it might be that its simply not a commercial possibility for GG, I can understand that. So what happens from here? What happens when the sheer volume of semi-working code gets too much to manage?
I'd suggest we're already at that tipping point, where the sheer volume of strung together code is making it ever more difficult to work with. Examples being that with each new release, we can see a load of bugs reappearing, or things that were working just kinda not anymore.
From a rational modern software engineering standpoint, not having unit tests and regression testing and all of that, well, its starting to show a bit. One of the key attractors of TGE is that its used in commercial products and has been battle hardened. Only, it feels like my perception of that stability is being eroded with new releases where I encounter bugs. The system needs a refactor, but its too big a job for anything but the core dev team I would think.
Not that it makes much difference to me, because I'm used to it. But there comes a time when a product simply reaches its shelf life. What do you do then? What is the way forward.
I guess I'm saying, whats the future? TGE2?
04/18/2007 (10:16 am)
Hey Todd,Well, Clarke did much the same thing about 3-4 years back. I bought into the aggregate model before then due to my experience with weapon class proliferation in W3D way back when.
I've really no clear picture why it hasnt been rolled into TGE/A, other than it would probably break a lot of existing hacks.
I guess what it boils down to is a core re-write of a lot of the TGE innards to better serve usability and modularity, outside of the hacking thats gone on for the last half dozen years. Now it might be that its simply not a commercial possibility for GG, I can understand that. So what happens from here? What happens when the sheer volume of semi-working code gets too much to manage?
I'd suggest we're already at that tipping point, where the sheer volume of strung together code is making it ever more difficult to work with. Examples being that with each new release, we can see a load of bugs reappearing, or things that were working just kinda not anymore.
From a rational modern software engineering standpoint, not having unit tests and regression testing and all of that, well, its starting to show a bit. One of the key attractors of TGE is that its used in commercial products and has been battle hardened. Only, it feels like my perception of that stability is being eroded with new releases where I encounter bugs. The system needs a refactor, but its too big a job for anything but the core dev team I would think.
Not that it makes much difference to me, because I'm used to it. But there comes a time when a product simply reaches its shelf life. What do you do then? What is the way forward.
I guess I'm saying, whats the future? TGE2?
#34
@ Phil
I think you make a lot of great points. To help on this front, if GG is interested in starting to use unit testing, I would be happy to work on setting up a cppunitlite++ framework (www.gamesfromwithin.com) as a resource. I think that this would be a great first step. Slightly off topic, but somewhat related, I just added a resource on adding minidump support to TGEA which may help developers track down some of the trickier crashes.
I find that it is really the game classes that need the most refactoring and shapebase is almost impossible to inherit from without ending up with something bloated. So, from my standpoint, implementing a component model and migrating things over seems to be working without completely halting my game work. But, as you are implying, it is a non-trivial amount of my time. From a commercial standpoint, I probably did it more out of interest then business sense. :)
@Tom
Sort of, but not really :)
What I mean is that I have been migrating my code over to the component model and implementing functionality as issues arise. For example, right now I have a really simple system for components communicating with each other. However, I intend to replace this system once I finish up a couple of components that I need now.
On the networking side, I have not yet implemented a solid model for the components. So, right now, individual components are ghosted over the network. This solves the bitmask problem, but adds too much overhead to the ghosting system (in my opinion). Eventually, it is my intention NOT to ghost any of the components, but to let the base object call the pack/unpack update on each of its components in a predictable order. If I left the component pack/unpack bitmasks as is, then there would be circumstances where component bitmasks are the same and you would get very bad pack/unpack mismatches. However, I am hoping to be able to assign bitmasks to the components as they are added to the base object. This would make the system 100% network safe, would not waste any bitmasks, and should be extendable beyond a single 32bit mask when necessary.
There are a number of interesting design decisions in making the system increasingly powerful. I am happy to focus on this specific improvement sooner rather than later if it is something that you are interested in. I am happy to share the code once I get it implemented, or if you have any thoughts or criticisms I would love to hear them.
Todd
04/18/2007 (1:11 pm)
Hey guys,@ Phil
I think you make a lot of great points. To help on this front, if GG is interested in starting to use unit testing, I would be happy to work on setting up a cppunitlite++ framework (www.gamesfromwithin.com) as a resource. I think that this would be a great first step. Slightly off topic, but somewhat related, I just added a resource on adding minidump support to TGEA which may help developers track down some of the trickier crashes.
I find that it is really the game classes that need the most refactoring and shapebase is almost impossible to inherit from without ending up with something bloated. So, from my standpoint, implementing a component model and migrating things over seems to be working without completely halting my game work. But, as you are implying, it is a non-trivial amount of my time. From a commercial standpoint, I probably did it more out of interest then business sense. :)
@Tom
Sort of, but not really :)
What I mean is that I have been migrating my code over to the component model and implementing functionality as issues arise. For example, right now I have a really simple system for components communicating with each other. However, I intend to replace this system once I finish up a couple of components that I need now.
On the networking side, I have not yet implemented a solid model for the components. So, right now, individual components are ghosted over the network. This solves the bitmask problem, but adds too much overhead to the ghosting system (in my opinion). Eventually, it is my intention NOT to ghost any of the components, but to let the base object call the pack/unpack update on each of its components in a predictable order. If I left the component pack/unpack bitmasks as is, then there would be circumstances where component bitmasks are the same and you would get very bad pack/unpack mismatches. However, I am hoping to be able to assign bitmasks to the components as they are added to the base object. This would make the system 100% network safe, would not waste any bitmasks, and should be extendable beyond a single 32bit mask when necessary.
There are a number of interesting design decisions in making the system increasingly powerful. I am happy to focus on this specific improvement sooner rather than later if it is something that you are interested in. I am happy to share the code once I get it implemented, or if you have any thoughts or criticisms I would love to hear them.
Todd
#35
I'll see if I can dig it up again. I think it was by one of the guys from Flying Labs. Made interesting reading as it suggested a far nicer way forward.
I think bitmasks are pretty nasty to be honest. I'd much rather have an object internally have a concept of "dirtyness" and have it know when to pack itself because of that (so the network hasnt got a mask so much as the object has its state invalidated).
My heads not in the right place to think right now though. More tommorow :)
04/18/2007 (2:32 pm)
I read a paper about a way to do network object updates without using bitmasks. I think it was in "Massively Multiplayer Programming" or some such. One of the charles river media books.I'll see if I can dig it up again. I think it was by one of the guys from Flying Labs. Made interesting reading as it suggested a far nicer way forward.
I think bitmasks are pretty nasty to be honest. I'd much rather have an object internally have a concept of "dirtyness" and have it know when to pack itself because of that (so the network hasnt got a mask so much as the object has its state invalidated).
My heads not in the right place to think right now though. More tommorow :)
#37
Back in the mud days we would use long long's for bitfield operations. Something akin to the following.
04/18/2007 (4:58 pm)
Quote:@Todd - Did this solve the "running out of bitmasks" issues that you frequently run into when extending ShapeBase? How did you go about that?
Back in the mud days we would use long long's for bitfield operations. Something akin to the following.
#define NEW_SHAPEMASK (1ULL << 43)
#38
I am pretty much of the same view here, I just don't see the need for gigantic paged terrains when nothing else pages with it and it takes ages to process. I would rather have smaller terrains that update in (semi) real time while editing and allow in editor modification - in short usability.
Height mapped terrain is still viable (even preferred) if you add in displacement mapping etc, and the voxel stuff is pretty cool too. I actually started playing with realtime updates of atlas instances but had to shelve it for the time being with all the other commitments I have. Without in-editor terrain editing atlas is pretty much useless for a large section of users and I would rather spend the time adding displacement mapping to the legacy terrain or writing something project specific from scratch.
04/18/2007 (6:26 pm)
Quote:
'm starting to get the feeling that actually the paging of terrain maybe isnt the best way of doing things. I know its great for geo-specific terrains that have to be very large. But for the vast majority of games, is this really the case?
I am pretty much of the same view here, I just don't see the need for gigantic paged terrains when nothing else pages with it and it takes ages to process. I would rather have smaller terrains that update in (semi) real time while editing and allow in editor modification - in short usability.
Height mapped terrain is still viable (even preferred) if you add in displacement mapping etc, and the voxel stuff is pretty cool too. I actually started playing with realtime updates of atlas instances but had to shelve it for the time being with all the other commitments I have. Without in-editor terrain editing atlas is pretty much useless for a large section of users and I would rather spend the time adding displacement mapping to the legacy terrain or writing something project specific from scratch.
#39
I need to re-respond to the bitmasks question....I shouldn't try to respond to these threads during lunch.
The component model DOES remove the bitmask problems with shape base. You basically have the full mask available for each component. If a single component needs the full mask, then we have other problems! The issue that I have now is that I am ghosting the components, which is silly (but was expedient). I intend to address that very soon as it an easy fix.
Phil, I'll take a look through the Massively Multiplayer book, thanks for the suggestion.
Todd
04/18/2007 (6:55 pm)
Phil & Tom,I need to re-respond to the bitmasks question....I shouldn't try to respond to these threads during lunch.
The component model DOES remove the bitmask problems with shape base. You basically have the full mask available for each component. If a single component needs the full mask, then we have other problems! The issue that I have now is that I am ghosting the components, which is silly (but was expedient). I intend to address that very soon as it an easy fix.
Phil, I'll take a look through the Massively Multiplayer book, thanks for the suggestion.
Todd
#40
www.charlesriver.com/Books/BookDetail.aspx?productID=62407
www.charlesriver.com/Books/BookDetail.aspx?productID=100596
04/19/2007 (12:52 am)
For reference, here are the books I was referring to:www.charlesriver.com/Books/BookDetail.aspx?productID=62407
www.charlesriver.com/Books/BookDetail.aspx?productID=100596
Torque 3D Owner Phil Carlisle
I do think it'd be useful to start a discussion about where technology is heading and where future torque based tech needs to be, but it seems that isnt what anyone else wants. So, I think I'll just keep quiet.