http://www.dyingduck.com/sotc/making_of_sotc.html
The fake volume particle part looks especially cool.
Dev ideas / technology
Moderator: Moderators
(yeah i sucked big time, get over it 
)Agreed, since volume particles would atleast need a bumpmap(or displacement map) for the engine to be able to know how to shade the particle. (so you end up having a pseudo 3d object that is shaded)Argh wrote:Altogether, that was an interesting article. I agree, the "fake-volumetric particle" thing is really cool. I can't help feeling, though, that they deliberately hid some very important details about how that technique is realised, though.
Also, having a noise generator can help in th randomness of the explosion or smoke..
You would also need shape controll (might be obvious) Alpha controll (density) Colour controll (what color is the explosion and where does it burn the brightest? (where the alpha is the closest to fully white)) and light emission of course.
So in shorter words: Would take ages to implement if done right.
Fascinating article about this (er, at least to this layman):
http://www.iam.unibe.ch/publikationen/t ... t_download
And another tidbit... I found the bits about mipmaps particularily interesting, since Spring has some specific problems in this area:
http://www.opengl.org/resources/feature ... glpitfall/
And, while I'm thinking about it... how are the rendering passes handled? I should take a look at the source, but I'm at work right now. Was thinking in particular about the way that shadows are generated...
Hmm...
http://www.opengl.org/resources/features/StencilTalk/
Hey... stencil shadows are "free", eh? This article is really, really sweet... and probably something JC et al have memorized, but hey...
http://www.opengl.org/resources/feature ... sld001.htm
http://www.iam.unibe.ch/publikationen/t ... t_download
And another tidbit... I found the bits about mipmaps particularily interesting, since Spring has some specific problems in this area:
http://www.opengl.org/resources/feature ... glpitfall/
And, while I'm thinking about it... how are the rendering passes handled? I should take a look at the source, but I'm at work right now. Was thinking in particular about the way that shadows are generated...
Hmm...
http://www.opengl.org/resources/features/StencilTalk/
Hey... stencil shadows are "free", eh? This article is really, really sweet... and probably something JC et al have memorized, but hey...
http://www.opengl.org/resources/feature ... sld001.htm
Didn't actually read it, but I really don't think any realistic smoke "solver" is going to be useful in an rts like spring. It's probably way to slow for most, and not worth the effort.Argh wrote:Fascinating article about this (er, at least to this layman):
http://www.iam.unibe.ch/publikationen/t ... t_download
This article is quite basic OpenGL, you will notice it when you don't upload mipmaps. Not really useful for any of the issues spring has (which is probably related to DevIL/DDS image loading or something)And another tidbit... I found the bits about mipmaps particularily interesting, since Spring has some specific problems in this area:
http://www.opengl.org/resources/feature ... glpitfall/
Spring uses nonlinear shadow maps, it seems nobody including SJ actually understands how it actually works, but SJ tweaked it to work IIRC :)And, while I'm thinking about it... how are the rendering passes handled? I should take a look at the source, but I'm at work right now. Was thinking in particular about the way that shadows are generated...
The rendering passes could be done more efficiently by better handling of vertex buffers and stuff like that, but nothing is wrong with it on a fundamental level (The rendering itself could use some lowlevel optimization I guess).
However, full realtime shadows using shadowmaps are slow no matter how you do them. Shadow blobs might be useful to implement, and maybe caching of shadowmaps or something if that would be possible at all (It might conflict with the nonlinearity of the shadow mapping).
They are cheap, but you need the silhouettes of the geometry casting the shadows, which basically rules it out for anything but FPS environments with sharp level geometry, no terrain, and small number of units visible.Hmm...
http://www.opengl.org/resources/features/StencilTalk/
Hey... stencil shadows are "free", eh? This article is really, really sweet... and probably something JC et al have memorized, but hey...
http://www.opengl.org/resources/feature ... sld001.htm
Heh, I figured I was probably tramping over ground you guys know really well, just was taking a look at some of these things for my edification. I actually found the whole bit about how OpenGL does lighting very interesting, and it brought up some questions:
Does Spring tesselate models during the lighting phases? If so, does it tesselate more, less, or the same depending on the distance from the camera?
Does Spring use a lower-resolution shadowmap as the viewpoint moves away from the camera? Earth 2160 seems to do that, and it also removes unit shadows entirely when a maximum distance is reached, but it still applies terrain shadows. This might be a good way to have your cake and eat it too- have it fade to simple blobs, then to nothing at "I'm playing NanoBlobs and I need to see the whole screen" distances.
How does the rounding shader work? It's very effective, and really makes round things that are carefully constructed look great, but I'd like to know more about how it works, because most of what I'm learning is through trial and error, and I am having some problems describing why some of the things I do (on the content-creation end) work, while other people doing similar (but not identical) things aren't getting the same results.
Lastly, Maestro said that Spring was optimized for quads, not tris. Is this really true?!? I mean, I know that quads are supported by OpenGL, but I figured that since the map geometry's using tris, that you were splitting each 3DO quad into two tris on each rendering pass, and then rendering double-sided. If tri-based S3O's aren't efficient, then I should probably start a new set of modeling tutorials, etc... but I hate modeling low-poly stuff in quads, it's just so bloody inefficient.
Does Spring tesselate models during the lighting phases? If so, does it tesselate more, less, or the same depending on the distance from the camera?
Does Spring use a lower-resolution shadowmap as the viewpoint moves away from the camera? Earth 2160 seems to do that, and it also removes unit shadows entirely when a maximum distance is reached, but it still applies terrain shadows. This might be a good way to have your cake and eat it too- have it fade to simple blobs, then to nothing at "I'm playing NanoBlobs and I need to see the whole screen" distances.
How does the rounding shader work? It's very effective, and really makes round things that are carefully constructed look great, but I'd like to know more about how it works, because most of what I'm learning is through trial and error, and I am having some problems describing why some of the things I do (on the content-creation end) work, while other people doing similar (but not identical) things aren't getting the same results.
Lastly, Maestro said that Spring was optimized for quads, not tris. Is this really true?!? I mean, I know that quads are supported by OpenGL, but I figured that since the map geometry's using tris, that you were splitting each 3DO quad into two tris on each rendering pass, and then rendering double-sided. If tri-based S3O's aren't efficient, then I should probably start a new set of modeling tutorials, etc... but I hate modeling low-poly stuff in quads, it's just so bloody inefficient.
The arguments for/against quads and tris are ancient and pretty basic, but here's a technical viewpoint:
http://herakles.zcu.cz/publications/dow ... necek-A-05
Basically, quads are more efficient, for things that are going to get sub-divided during a render step, but tris are more efficient, for things that need to have curvature, and certain types of geometry just plain requires more quads than tris (not to mention that box-modeling is, at least for me, less inuitive than simply doing simple booleans, extrudes, etc., to arrive at final geometry).
http://herakles.zcu.cz/publications/dow ... necek-A-05
Basically, quads are more efficient, for things that are going to get sub-divided during a render step, but tris are more efficient, for things that need to have curvature, and certain types of geometry just plain requires more quads than tris (not to mention that box-modeling is, at least for me, less inuitive than simply doing simple booleans, extrudes, etc., to arrive at final geometry).
Booleans are a solid-body modeling technique used in NURBs modelers, mainly. It's an operatio where you remove, combine, or get the intersections between two solids. It's a technique that's very handy for building very complex geometry in a big hurry. For game-modeling, I use it to quickly build up the big, complicated objects that require a lot've surface detail, along with mirroring and other things that you're probably very familiar with. In the end, it's just a time-saving tool.