It has come to my attention that people (including me) are having problems rendering large objects at large distances. One solution I can think of is having a skybox that would replace large objects one they get two far. For example if you have a plaint that is past the far plane the sky box would use a texture rendered to render the plaint onto it’s self so you would still be able to see the plaint. This would be a grate addition to jme if someone wants a slight challenge.
… would be nice if this would work for terrain-blocks / chunks too.
maybe this could be done with imposters ?
"Badmi" wrote:
For example if you have a plaint that is past the far plane the sky box would use a texture rendered to render the plaint onto it's self so you would still be able to see the plaint.
We have very large object in represented in big detail. We want to show small dot somewhere in background, because it is so far away. Idea of rendering it to background image is good, but HOW to render it ? Obviously, you cannot render it to 1millionX1million pixels texture and scale down. You need to create VERY simplified LOD mesh for it, or even a flat texture impostor to be able to render it to texture. Problem is, if you have such mechanism for rendering extremly simplified objects at large distances, you can use this mechanism directly in scenegraph, without prerendering it to texture...
I think that render-to-skybox idea is good only to optimize rendering speed (so you won't have to find positions of thousands of stars each frame) - but does not help to solve the large-object-at-large-distance LOD problem.
I am talking about rendering things like planets that still looks big(Perhaps a radius of 3 inches on the screen once rendered) when they are far away. For stars you can just use points but theas are two big. With large objects part of the object may be close wile part may be far. I am not as concerned with speed as with the fustrom limit.
This can be solved with imposters and DiscreteLOD. Where at the lowest level of detail (imposter) you keep the node a consistent distance from the viewer. You’d still have to keep track of real distance though for switching LODs back (but that’d be trivial).
"Badmi" wrote:
I am talking about rendering things like planets that still looks big(Perhaps a radius of 3 inches on the screen once rendered) when they are far away. For stars you can just use points but theas are two big. With large objects part of the object may be close wile part may be far. I am not as concerned with speed as with the fustrom limit.
Star was an example - it is similar to planet, just bigger and visible from greater distance. You cannot use same geometry for closeup of planet and when seeing it from distance of millionds of kilometers. It is not just a frustrum - you will start to hit resolution of float numbers. To be honest, you are asking for trouble with anything outside range of million units (where unit is smallest difference between object details). For example, with spaceships, with, let's say, 1 meter unit (so they are at least umpteen meters long to have some detail), you cannot hope to play with more than 1000 km of space around the ships using normal computations. Given size of real planets, this rules out any normal rendering of them. You will need specialized routines, which will render them smaller and closer, to fit in float range - frustrum is secondary problem, as you can trivially sort the objects/triangles and disable z-checks/writes.
"mojomonk" wrote:
This can be solved with imposters and DiscreteLOD. Where at the lowest level of detail (imposter) you keep the node a consistent distance from the viewer. You'd still have to keep track of real distance though for switching LODs back (but that'd be trivial).
Can you clarify what you mean?
I have a small solar system thing that I am writing to get the hang of jme.
in this I have a sun object, which is everpresent. I suppose this is kinda similar to your problem. I achieve this simply by placing the sun object near the periphery of vision and update its position manually.
so, if sun is at (0,0,0) and you are at (50000,0,0) and the far clipping plane is at 100, then I say before drawing every frame → sunPos = normalise(you - sun) * 99;
for example
"zenic" wrote:
I have a small solar system thing that I am writing to get the hang of jme.
in this I have a sun object, which is everpresent. I suppose this is kinda similar to your problem. I achieve this simply by placing the sun object near the periphery of vision and update its position manually.
so, if sun is at (0,0,0) and you are at (50000,0,0) and the far clipping plane is at 100, then I say before drawing every frame -> sunPos = normalise(you - sun) * 99;
for example
in this I have a sun object, which is everpresent. I suppose this is kinda similar to your problem. I achieve this simply by placing the sun object near the periphery of vision and update its position manually.
so, if sun is at (0,0,0) and you are at (50000,0,0) and the far clipping plane is at 100, then I say before drawing every frame -> sunPos = normalise(you - sun) * 99;
for example
How dose that scale the sun to the right size?
well, in my case I use a billboard for that distant object, which is basically just a sun halo thing. I think I took one of the textures from the lens flare example, can’t remember.
either way, you can easily scale it if you want. take the distance of you to the sun, and set the local scale of the sun based on that distance. You will probably want to have a point at which the sun is too far away. kinda like a far far clipping plane. if not then you can set the scale to a fixed value if it drops beyond a certain value. for example, if (distance < 50000) scale = .1 + (50000-distance)/50000, else scale = .1.
but i am using space, where error is tolerable. If you were using this in a must be accurate kind of flight-simulator for mountains in the distance, you might want to scale your mountains using the same formula that the projection uses. look up help on things like gluProject to find out about how that works. note: it is more maths heavy…