red knight

Thanks god, I have been out of reach for almost anyone for 3 weeks... If I would have known that the business travel I did was going to be that hard on my time I would have tell you all about it. If you have anything serious for me to take care, either post here or drop me a PM. Greetings Red Knight

That looks like an unsupported video card (not Shader 1.1) or an outdated/windows provided graphics card driver. Greetings Red Knight

I knew about that, cause you resisted to use the Component approach that is heavily rooted on XNA, the point is that even though there are millions of way to do the same stuff at this moment there is no One Size Fits All Solution. On the other side, OGL is already showing its age in complexity so I doubt (and I am not saying it isnt possible) that there is any clear advantage to move in that direction. Sure SM4 is cool, but there is nothing that requires you to implement the functionality in it either. As I said, Chapter 1 in GPU Gems 3 is a showoff that may be posible to be done straight in XNA when we need it anyways. So I wouldnt bother too much about it either now. Going with a simple solution is the best tradeoff at this moment. Greetings Red Knight

Never forget that the most innelegant solutions sometimes if coded correctly can be the most elegant of them all ... instead of having the ListAccesibleNeighboars what you can do is define a "lambda" in C# 3.0. In C# 2.0 (what we are using) the syntax is a little more nasty, but can be implemented anyways. The solution is to have a delegate instead of "inheritance" where you give all the information to select if it can goes or not to the unit instead... Suppose you can do something like this in the A*: Foreach posible cell arround if unit can move evaluate certainty of movement The trick is that unit can move can be parametriced as a Func delegate . So you can do that without the A* algorithm notice that it is handling an special case. You can even go overboard and do that for the Foreach part of the statement too... If you have any problem designing it, let me know and I can send you some example code that show the approach in action. Greetings Red Knight

Yes, big problem indeed. The problem there is that the 3D Terrain is created in the geometry shader something neither XNA or XP support. XNA by design, DirectX on XP by a driver issue. If you are really completely absolutely sure that you want to implement that and you are willing to sacrify the XBox360 support there are ways to implement that on XP (not Vista yet) using CUDA. However, that approach is more of a showoff than a REAL thing. They are showing that they can do Marching Cubes on the GPU ... Until now I still dont understand why you want to generate the 3D Terrains on the fly, or better why not to simplify that using standard Stripping (SM1) on CPU to do the geometry generation (even Geometry Clipmaps would be enough, GPU Gems 2) on a Fractal bitmap. You can then select the place for the big objects using leveled "blueprints" (like putting the same value in the bitmap for a complete house so you get a levelled terrain to put the house in --- Try SimCity 4 to see that approach in action ). If you are willing to use SM2 you can even do the displacement on the GPU, several technics exist like the one for the water in GPU Gems 2. I think geometry clipmaps implement sort of that too. Basically what you do it: On Loading (CPU): Create a fractal terrain. If required by the rendering technic create the terrain geometry Select where you are going to put BIG objects For each BIG Object Level the terrain bitmap using the BIG Object blueprint On Rendering (CPU+GPU): Render Terrain using any Displacement Technic (realtime or precalculated -- that was done On Generation --) Render BIG Objects Read my post about OpenGL stuff. Greetings Red Knight

Ok, speaking with a firm step in the technical background I will do a couple of myth debunking just for the sake of it ... you are reading too much slashdot There is a really important reason why XP wont support DirectX 10 (SM4 is just how to say it... an unlucky bystander in that commercial war), to the point you have to reimplement the kernel of XP to support the features proposed by the DX10 spec (something that it doesnt make sense from the commercial standpoint). Such things are related to the Device Driver Model of XP that are plainly not posible to be done without a new DDM. SM4, as is, is not a DX10 thing, but they are very enhanced by the rest of the DirectX 10 spec (everything comes in one package). That is why OpenGL can provide that funtionality, because it puts the burden on the developers side instead of on the DX10 API/Driver developer. I can name the changes that make that simply not posible, but it doesnt makes sense, you can read about it from the blog of the DX10 team. Not entirely true... I would say as Tim Sweeny pointed out (something that I agree) that DirectX10 is the last API that will have an impact in the Realtime Graphics world ... http://www.tomshardware.com/2008/03/11/tim..._graphics_api_/ ... Why?? well because with the GPUs being like a General Purpose Stream Processor, you can go an program your own API with a raster engine that fits your needs without ever bother with DirectX itself ... You want raytracing?? Go and program in CUDA the ray tracing engine and you are done ... The changes done to DX10.1 are not that big to call it "obsolete" either. Because they were not programmed with SM4 in mind and because they hadnt used the specific features of DX10 for compatibility sake. But after time passes DX10 will be used more an more games that really makes use of them, not because the feature set, but because of the flexibility it provides. Shader development today is hard, because of you have to seamlessly switch between multiple ways to do stuff (that will change when CUDA style APIs and that kind of stuff do really start to make a difference as they treat the GPU as an standard parallel processor)... DirectX11 maybe??? I do agree for now , but knowing the timeframes we manage, it is not that much in 2 years ... always remember computing is about tradeoffs, in this case easy of development against processor requirement. Greetings Red Knight

One minor correction: In my post it sais: Using BSP though is counterproductive as the entire terrain because a polygon soup model (in the extreme case). Should have been read: Using BSP though is counterproductive as the entire terrain BECOMES a polygon soup model (in the extreme case). However, it shouldnt change the interpretation of not using BSPs. For the Cell you can create the Cells rule engine from the geometry pretty easily without human intervention (As long as you agree on the scale of the models). You load the terrain + objects and then for each valid cell position to check to see if there is a blocking polygon in it. Blocking polygons are those that have a certain angle non parallel to the floor or above a certain threadhold on cell covering (to be able to have hills and stairs). Probably it would be important to be able to use smaller cells (than the reference that the soldier/unit uses to be able to handle the stairs as a common case instead of an special case). Greetings Red Knight

The fracturing and destructability is doing procedurally, at least for big models (that is how it is done today) the artists just hints the engine where to "cut off" the elements. Or what an artist do is chop the model in parts if required (but that is something that you can do procedurally too on a Geometry build pass. That is why I say lets forget about it, and concentrate on that part. Using BSP though is counterproductive as the entire terrain because a polygon soup model (in the extreme case). So it cannot handle properly (without too much work and many restrictions) models that change place. Greetings Red Knight

I think we are mixing stuff so that it got complicated; indeed a FOW texture is an encoding of that information. However you mix cell state for destruction, something that is very geometry oriented, with FOW which is pixel oriented. What I argue here is that "destructible" in fact spawn multiple stages of destructability. Cell destructability is a discrete simplificable problem for things such as Fire, Smoke, Game Rules, etc. While it is not from a shading point of view, for example Fire+Smoke do have a visual representation that requires a volumetric definition and others that do not (SuperParticles/Voxelization/Etc against Impostors). With FOW with the creation of a FOW texture you are decoupling the real world state with the shading version of it (what you require to paint the pixels). You may not need that information per/se in the engine as long as you can generate it from the entities (units) position. Remember as a general rule of thumb, everything that can be calculated/derived from other information source is better to keep it that way; because if you have both states the posibility of inconsistencies is higher, with added complexity+more efficience problems. That is why I always say, create your world in such a way that the domain map as closely as posible to their intend. If you have entities that move in the world, first you need a world, and then the entities to move in it... Entities are discrete units, while the world can be a bunch of polygons or whatever representation you like, as long as you can respond easily and/or efficiently if I can move there or not . The point is that with Cell based objects you may be choosing (I may be wrong) a too restrictive model that you are going to pay later on. As long as your units know if they can move to a certain place or not that is enough. If you then want to restrict your world representation for the purposes of entity moving, it is up to you, but the domain model or the World is far more richer than that and choosing a path using those assumptions is plagued with unforseen risks at this moment. More if you think how the actual shading is done today. I would say, forget about destructable models now; concentrate in rendering all what you have and have a restricted gameplay where you can use the door to get it, and after that see how to destruct a house correctly cause the underlaying assumption continues being the same, either you can move there or you cannot. Hope that makes sense. About the visibility, to fix things up lets call "visibility" the discrete problem where one unit can "see" other unit and "pixel visibility" the shading problem. Greetings Red Knight

Ok lets start with Isomorph (that is the simpliest one )... Formally that means that:Given problem P and P' and S a solution to P then P and P' are Isomorph if there is a function F such that F(S) is a solution to P'. In the example: if you have a solution of P (in this case rendering visibility in shading) you have also a mapping that allows you to solve P' (discrete visibility) About Deffered Shading, even though you are correct about the procedural the concept goes far beyond than that. For example, most shadowing algorithms requires you to render from the light source or create extruded geometry from the light source. In deferred shading, your geometry from the eye solves the visibility problem because from that you can know if something is seen or not; now the point is: do the engine must know about it??? is the visibility required for a "shading purpose" or for a game rule? Trying to answer those questions even if vaguely will give you a couple of hints. Like for instance for "visibility" to know if someone is inside the area (discrete problem) where it should be seen is different from the visibility if the alien even if seen is under a smoke curtain. The degree of detail needed for one problem is orders of magnitude smaller than the other. With a bounding box for each element and a simple ray tracing approach you are almost done for the 20 units you care about. (Even though doing it in the CPU is similar at how it could be done on the GPU). On the other side, the other is a shading problem where far more detail is needed (to the pixel level). So in short how would I do it? Use a gross aproximation for the entities (knowing if an entity should be seen game rule based... radius or ray shooting, more complex are posible but for most purposes that is almost enough). Select active entities to render. (everybody seen and inside the FOW) Create a alpha style texture with the FOW (very simple to do) -> as if you are looking from the top Render ( Terrain, Entities ); -> remember to pass the new FOW texture Now on the Shading part: Render using the method prefered (direct or deferred)... Postprocess the rendered image darkening or desaturating colors where in the dark FOW. (Substractive filter or Desaturate Filter) Done Why did I mention deferred rendering? Because the post processing step requires most of the typical information that is generated in a Deferred Shading Renderer so you are doing the work anyways. The idea is that the rendering do not encode colors but properties of the pixel (Depth, Color, even things like FOW ). It is sorta complex at first but after some times it makes sense... or at least I am trying to explain it in such a way that it makes sense. Did it makes sense? Greetings Red Knight

In current hardware believe me that it is better to just draw black than do not draw (doing a discard) ... the idea is that the multiple framebuffers do not render the image but attributes (enabled by MRT - Multiple Render Targets) and those are composed at the end. Deferred shading powerpoint I posted show that at the extreme as the extreme case is what deferred shading is. Now, if the visible part is just another attribute you are done, when composing you know what to do ... Thats the reason that I say that in the extreme case rendering visibility is isomorph with the shading process. Take a look at this 2 presentations in order: http://www.gdconf.com/conference/archives/...tchard_matt.ppt http://www.gdconf.com/conference/archives/...dreich_rich.ppt Both shadowing, visibility and what I am talking about start to make sense ... If you can get GPU Gems 3 take special attention to the following articles: Chapter 13: Volumetric Light Scattering as a Post-Process Chapter 19: Deferred Shading in Tabula Rasa Chapter 28: Practical Post-Process Depth of Field Chapter 8: Summed-Area Variance Shadow Maps And in particular, this one shows the solution to another nearly isomorph problem: Chapter 30: Real-Time Simulation and Rendering of 3D Fluids There are better ways to do this in the CPU but I will show you how to convert a discrete visibility problem into a shading one just for the purpose of demostration. Suppose that you have all geometry and draw in Black all static things and in a color based on an Unique ID all entities. Now if you read back that image and find all distinct pixel you would get something like this: { 0, Id1, Id5, Id8 } If you discard 0 that is all static geometry, you can now map all the Ids into an entity... Now do the render with only the entities whose Ids match you are done... you have solved visibility This problem is isomorph to shoot 1 ray per pixel in ray tracing . There are reasons while it is much faster to do on the CPU, but doesnt means it is not posible the other way arround. For some problems like FOW, shadows, etc it is much faster to do that on the shading process using the GPU than on CPU. That is why I separated a discrete problem with the rest Greetings Red Knight

It is true that all of them are related somehow, however there is a bigger relationship between FOW and Night Mission than with those 2 with Destructable terrain. However, it is not true that the facility models approach is not viable; in fact, you will see that it is exactly the way to go. I will try to elaborate further to give an ideo on how that should be implemented. First, why are they related? Because both FOW and Night Mission share the very same root, discovering when to show something and to some degree on how much detail; that means it is a visibility problem. Furthermore, lets suppose that the visibility is taken care, both too have a shading component. Basically deciding how to calculate the surface color (or the pixel color to be true in this case ). In the case of FOW you have a very simple formula: If there is someone arround you fully see entities and terrain/objects (this is a discrete problem solved by the game engine) else if you have been there already but are outside you have to show only terrain/objects else you shade in black :) So think FOW as a mask in the shading process if the pixel gets projected into the mask (a ray from the eye collides with the mask before hitting an object) -- this goes inside a pixel shader btw -- then you shade in black. To make things more interesting the mask threadhold can be shaded differently for "aestetical reasons" if required. But nothing prevents you to know that when shading. On the other hand, the entity visibility is just an drawing level problem, if the entity is inside a specified radius then it is drawn; otherwise it is not. Simple as that. So the only difference is wether you push something to be drawn or not based on a certain rule. Destructable Terrain is more a vertex/object problem that later has to be shaded using those very same techniqs using FOW and Night Missions (BTW Night Vision is just a change in the lighting equation only --- pixel shader again and some extra operations on the vertex) Some information on lighting equations and shaders: http://www.slideshare.net/mobius.cn/advanc...r-meltdown-2005 A survey on lighting techniqs: (check the latest slides) http://www.slideshare.net/wuzziwug/renderi...-in-video-games Another way to do rendering (lighting): http://en.wikipedia.org/wiki/Deferred_shading http://www.talula.demon.co.uk/DeferredShading.pdf And this is STATE OF THE ART: http://www.iit.bme.hu/~szirmay/gpugi_link.htm For destruction of models you can take a look at this: http://creators.xna.com/Headlines/developm...01/Shatter.aspx If you can mark some triangles to use this effect you have instant destruction of elements ... better effects though are obtained with this on volumes though.

One thing strikes me, aim for 10K tris at least... and even though, dont worry if you need 100K just make it look "Great" and then we can generate the bump map out of the High Poly versions with Melody. Greetings Red Knight

BTW you can go a little overboard with this and use the Where as a Lambda condition in C# 3.0 (Visual Studio 2008) or in preparation as a delegate in C# 2.0. That helps a lot for intersection queries. An example of that can be found here: http://blogs.msdn.com/lukeh/archive/2007/0...r-in-c-3-0.aspx Greetings Red Knight

The other is to post in the Algorithms mailing list for that information: https://lists.sourceforge.net/lists/listinf...algorithms-list Beware they are really PROs so if you are asking too an uninformed question you will get no reply. I suggest first to check out the archives: http://sourceforge.net/mailarchive/forum.p...algorithms-list and then if that doesnt help go and ask a question. I have been looking over the information and there are at least two interesting approaches. One is to create scripted destructable objects and destructable terrain (terrain deformations + soft particles for debris) and the other is freeform deformation and destructable environments... I would move toward the first approach because you can do the terrain deformation and soft particles first and then move into the destructable object (art scripted) and then to more procedural approaches for that last one. Greetings Red Knight