I will be trying to learn how to use terrain and LOD. However, there is one question which immediately comes up.
For terrain in the distance, do I have to increase the FarFrustum, and hence the NearFrustum of the camera? If I do this, the objects close to the camera will not be rendered and a lot of objects far away are rendered uselessly. The bigger problem is in the first part, as I can manually detach objects far away and just show the terrain.
Thanks in advance ^^
Why do you need to change the frustum? Terrain handles the LOD on its own without the frustum. Or are you trying to render two different terrains: one really far off (hence the frustum cull) and one closer and high detail?
The default FarFrustum is 1000.
If there is terrain 2000 WU away, then that wonāt be displayed, no? Iād have to increase the frustum. Or does the terrain render regardless of the cameraās frustum?
The terrain patches out at that far distance will be culled by the frustum and you wonāt see them. But you will see everything up until that far clipping plane.
And thatās the problem 
If I increase the far frustum to 10000, then anything within 10 wonāt be rendered. Are there any workarounds?
Wait what? It starts clipping things close to you when you only adjust the far frustum? That should not be. Does everything get clipped close up or just the terrain?
10,000 is quite large. Does 2000 work better and the problem is just exacerbated as you increase the clipping plane?
nehon (I think it was him) told me to increase the near frustum by the same ratio I increase the far frustum. If I make it 2000, then anything within 2 WU arenāt rendered. Although I guess I can live with that 
I think that can help with depth fighting at far distances, but thatās just a guess. And you might not need it.
Obviously though, if you increase the near frustum plane then objects in front of you will get culled.
In terms of manually removing/adding objects that are inside the frustum but far away, you might eventually want to look at āimpostorsā (2d sprites that represent 3d objects). You usually do this as the lowest lod level of the object. You can remove objects entirely that are really far away, but still show the terrain; it might look odd though: barren hills with no features.
1 Like
@memonick said:
nehon (I think it was him) told me to increase the near frustum by the same ratio I increase the far frustum. If I make it 2000, then anything within 2 WU aren't rendered. Although I guess I can live with that :)
I didn't said that exactly.... You were trying to set the far frustum to 100000 or something like that... you can handle a frustum from 1 to 2k with no depth precision issue...
Also to cope with this issue you can make some mountains around or buildings/vegetation that are hiding the horizon somehow so that the player can never see it.
Also you can use fog to smoothly hide things that are far away.
I read an article on the wolffire blog that was awesome... they were blending the sky and the land at the horizon. The result was swooshing...
Edit : and here is the link http://blog.wolfire.com/2009/07/blending-land-and-sky/
1 Like
Thanks a lot both of you
@nehon said:Edit : and here is the link http://blog.wolfire.com/2009/07/blending-land-and-sky/
Whoa! I love the final picture, really pulls off the desert look.
yeah I recommend reading this blog itās very inspiring
Those type of ā90āsā effects should not be promoted imo. There are real time atmospheric scattering shaders available these days.
@androlo said:
Those type of "90's" effects should not be promoted imo. There are real time atmospheric scattering shaders available these days.
Isn't it always about the result? I mean, it has to:
a.) look good
b.) be easy to implement with the knowledge of the writer
Above effects looks decent, and seems to be implementable quite straightforward. So i don't see any drawback in using it. Why would i want to use something else, if this simple technique does?
Or else, why should i read about atmospheric scattering and familiarise myself with that topic, when i have this decent looking approach readily available?
I mean yeah, when i want to make the next gen AAA game, it'd be different, but when i want to get some decent things done it's good enough i think.
@androlo said:
Those type of "90's" effects should not be promoted imo. There are real time atmospheric scattering shaders available these days.
Yes but that comes with a higher performance cost.
I'm not an adept of "exact physic phenomenon" implementation, but I know you are ;)
Also those are not 90's effects, come on!
Any ideas how one can blend the horizon and the sky?
@nehon said:
Yes but that comes with a higher performance cost.
I'm not an adept of "exact physic phenomenon" implementation, but I know you are ;)
Also those are not 90's effects, come on!
Also, for atmospheric scattering to be the perfect solution requires all of the terrain to be rendered between the player and the horizon.
The above effect is about masking that issue that there is no terrain beyond a certain point and yet you still have a detailed horizon in the distance. And it can be tough to tweak atmospheric scattering to match the artwork in that case.
@androlo said:
Those type of "90's" effects should not be promoted imo. There are real time atmospheric scattering shaders available these days.
Computer Graphics is all about cheating. If it looks good then it's good.
@nehon
Itās actually not that advanced tho. Thatās the thing!! The OāNeill version is quite easy to use, and with a GUI itās be possible to just try different parameters and check how each one affects the sky in real time. In the end thereās only like 3 or 4 parameters that really matters.
Itās not that slow either. The frag shader is trivial, and the scattering loop in the vert shader only has to be run 4-5 times to produce descent looking results, and there is only math in it, no texture fetches etc. I noticed the skydome can be pretty sparse as well using the OāNeill system, which saves a lot of calculations. Even my crap computers run them without too much effort.
Ogitor has implemented the SkyX shader and lets you tweak it inside the editor. Iām trying to get the same thing working with jME, but my sky system is a lot less evolved then SkyX. Iāll put things in gradually.
@pspeed
I was thinking more like a fog. The skydome itself is colored by AS then the same light functions are used to color the fog (sample the dome, basically) and then blend etc. Also you get the HDR colors right away with that method, if thatās what you want.
I use gradients myself, but thatās just temporary. Gonna switch to dome sampling probably. Read some article by a cryengine dev, they seem to use dome sampling. That may have been some time ago tho, canāt remember when the article was written.
EDIT: This is is for blending geometry with the sky. It would of course work regardless of whether you use dynamic impostors for distant terrain, or these type of static ones.
@memonic
Use scattering or just plain old fog Iād say? Perhaps a distance based blur as well. Itās fast, simple and looks good.
You can also make the fog vary in color and intensity depending on world height and other parameters, not just distance. For my sky system I even added a specular component to color the fog white/yellowish near the sun. @kwando suggested it, and linked to some guys site. That guy had a lot of good tips on how to use fog, and even source code. He also had good screens that shows how it ought to look. Gonna look for the link.
@androlo said:
@nehon
It's actually not that advanced tho. That's the thing!! The O'Neill version is quite easy to use, and with a GUI it's be possible to just try different parameters and check how each one affects the sky in real time. In the end there's only like 3 or 4 parameters that really matters.
It's not that slow either. The frag shader is trivial, and the scattering loop in the vert shader only has to be run 4-5 times to produce descent looking results, and there is only math in it, no texture fetches etc. I noticed the skydome can be pretty sparse as well using the O'Neill system, which saves a lot of calculations. Even my crap computers run them without too much effort.
Ogitor has implemented the SkyX shader and lets you tweak it inside the editor. I'm trying to get the same thing working with jME, but my sky system is a lot less evolved then SkyX. I'll put things in gradually.
I'm looking forward to this. ;)