Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Feb 2002
Offline Last Active Oct 22 2016 11:30 AM

#5120394 Cloud Rendering

Posted by on 31 December 2013 - 07:25 PM



  My clouds are dynamically lit and also have in-scattering, I have normals for the clouds which are computed in the pixel shader during rendering.


My lighting calculations aren't finished though (it's only a few hours work) so there maybe some lighting requirements I'm missing?


Could it be lack of self-shadowing and maybe not using exponent on the noise, which is creating very wispy looking clouds in your screenshot? Though obviously sometimes wispy clouds are desirable, they often don't look very volumetric.


My go to resource for cloud rendering is a rather old thread here on gameDev by Yann-L, sadly the pictures are all missing now, but they looked impressive at the time and i'm pretty sure the techniques are still in use today. Though the site redesigns have made the posts harder to follower (quote blocks seem to have been lost and so a reply and quote all flows together), there is still plenty of good information to be found in Yann's posts, probably worth a read.



Yann's work was pretty amazing. These days this is probably the best paper I've seen on sky rendering: http://www.hpi.uni-potsdam.de/fileadmin/hpi/FG_Doellner/publications/2012/MED12/paper_1056_cr.pdf


Here's the video: https://www.youtube.com/watch?v=t8ibsEl0kAI


The clouds are based on a Game Programming Gems article that traces rays through a heightfield. The results are pretty convincing. 

#5108984 Create a parser for blender.obj file to use in Opengl

Posted by on 13 November 2013 - 10:08 AM

Alright, my apologies. I don't disagree that using a single vertex and index buffer per subset is better than using one per positions/normals/texture coordinates. I do disagree that collapsing vertices and indices down is difficult. Identifying unique vertices is a matter of looking at the triplet of indices specifying a vertex. 


Like I said, your game probably isn't going to be using any standard format natively. If you just want to load in a standard model file to mess around, writing an OBJ loader is quick to do. I honestly thought it was pretty fun and educational. Could your time be spent better elsewhere? Probably, but it's not like you are wasting a month trying to convince Collada or something to load. assimp is a fine solution. But if you want to spend a day or so, you can write an effective OBJ loader.

#5106805 Looking for procedural 3D mesh generation resources

Posted by on 03 November 2013 - 07:09 PM

Maybe not what you are looking for, but this a pretty good presentation:



#5099441 Geoclipmap concept & tutorial?

Posted by on 07 October 2013 - 07:05 PM

You didn't find the concept? Oo




To be honest, I seriously dislike replies like this. There are plenty of reasons why someone won't find "obvious" research and the whole lmgtfy just wreaks of unnecessary arrogance. Man up and give the guy a link or two, or don't bother responding. 


On that note, check out the GPU Gems chapter on this: 




There are better ways of handling things these days. If you are using D3D11 look into using tessellation. If you are using D3D11.2 there's hardware support for virtual textures. 

#5080787 SIGGRAPH 2013 Master Thread

Posted by on 26 July 2013 - 11:35 AM

The selfshadow blog has a bunch more links to courses, talks and papers. The massive worlds course looks pretty cool, nice to see some talk about hardware virtual textures. 


EDIT: Here's the url: http://blog.selfshadow.com/2013/07/24/siggraph-2013-links/

#5055600 How does shadow mapping work?

Posted by on 21 April 2013 - 04:04 PM

Sure, I'll give it a shot. The idea is you need to be comparing depth values in the same space. When you generated your shadow map, you used a certain model, view, and projection matrix for a piece of geometry. When you render the scene from the camera's point of view, you have a model, view and projection matrix as well, but this results in a value that's in a different space. When you render from the point of view of the camera (the second pass), you must also transform by the lights model, view and projection matrix. This will give you a value that's in the range [-1, 1] for X, Y and Z. Texture coordinates are in the range [0, 1] though, so you must scale the value by .5 (note for OpenGL you must also negate the Y texture coordinate). After doing this you'll have texture coordinates to look into the shadow map and see what depth value the light "saw". You also have your pixel that you transformed into the same space, so you know what its depth value is. If the depth value you have for the pixel you are drawing is less than the depth value in the shadow map, that means the pixel you are drawing is closer to the light than what the light saw. In other words, it's not occluded and thus should not be in shadow.

#5047447 drawing clouds in a flight sim

Posted by on 27 March 2013 - 07:00 PM

but a box mesh wouldn't look right. i suspect MS fight sim 2004 used meshes like the cardboard dividers in a case of wine. IE stacks of quads in all 3 directions, with alpha blended cloud images on each quad.

If your are curious about Microsoft Flight Simulator 2004's clouds, HERE'S the paper.

#5025925 Robust Shader Systems for a Game Engine (Advice&Discussion)

Posted by on 26 January 2013 - 07:46 PM

I'd recommend taking a multi-layered approach. First, decouple your constants from your shaders. Chances are most of them share a number of constants. Be consistent in your naming.

Next, look at a rapid prototyping approach. There was a pretty good article by promit on this a while ago, but the link appears to be dead. The idea is to scan a shader for constants and link it up to a provider class. In my implementation, I search a class for public properties (C#, though you can do this in any language), and link it with the associated constant in the shader file. This frees you from a lot of boiler plate code and lets you spend time tweaking a shader as you see fit.

Once shaders are finalized, you can write concrete classes that avoid the reflection and other overhead with the rapid prototype approach.

#5021651 Grass and what to do

Posted by on 14 January 2013 - 09:18 PM

Let me begin by saying, i know that grass is not a majorly important thing since most of the players will simply pass by it without caring too much, but the concept is to make something that is appealing to the eye and non-resource intensive. Before you go saying "that is impossible" i would argue that by using art and optical illusions you can very much do this. The question is how does it translate into code or what are the best practices.


Many games today render grass as a flat plane with a simplified texture over it. This process is not bad but one must ask the question of how to add depth. More planes? Assuming you do figure out a proper method what type of lighting should be applied, how do shadows work?


I have seem some games that add an ambient shadow to the base, where as others do not care about shadows at all and simply ensure the grass matches the tone of the mesh it is attached with.


My overall question is, how would you, fellow coders, do your grass?


I've yet to see a better looking technique than Kevin Boulanger's implementation