next »

[Patheros]

I don't think so. The nearer the far clipping plane, the better is depth buffer precision. But I will test the performance impact of that.

I await your results.

Can't you achieve your goal by using an additional render pass?  You could draw the planet in its own (probably display list?) scenegraph rendered behind the primary scene graph with the short clipping distance you desire.

I've thought about that. I've hardly done anything with render passes so far. I probably will look into it before I start implementing anything.

[Marvin Fröhlich]

I've thought about that. I've hardly done anything with render passes so far. I probably will look into it before I start implementing anything.

Easy:

Code:

BranchGroup farScene = createFarScene();
BranchGroup nearScene = createNearScene();

RenderPass farPass = RenderPass.createPerspective( farScene );
farPass.getConfig().setFrontClipDistance( 4000.0f );
farPass.getConfig().setBackClipDistance( 5000.0f );

RenderPass nearPass = RenderPass.createPerspective( nearScene );
nearPass.getConfig().setFrontClipDistance( 1.0f );
nearPass.getConfig().setBackClipDistance( 500.0f );

env.addRenderPass( farPass );
env.addRenderPass( nearPass );

This should basically work.

Marvin

[Marvin Fröhlich]

I don't think so. The nearer the far clipping plane, the better is depth buffer precision. But I will test the performance impact of that.

I await your results.

I used the Q3FlightTest, where the near clip plane currently is at 1.0 and the far plane at 2000. I checked, the maximum distance of shapes during a flight, which was at about 40 and therefore set the far clip plane to 100. The FPS were about the same. So I guess, it makes no difference in performance concerns.

Marvin

[Patheros]

Thanks for the code and the test results Marvin. I will definitely try to use them as soon get around to it.

[Marvin Fröhlich]

I've added the LODSwitch Node. Please have a look at org.xith3d.test.scenegraph.LODSwitchTest. And please tell me, if it serves your needs.

Marvin

['n ddrylliog]

I've added the LODSwitch Node. Please have a look at org.xith3d.test.scenegraph.LODSwitchTest. And please tell me, if it serves your needs.

It needs several Shape3Ds or does it make the "downsampling" itself ?

[Marvin Fröhlich]

It needs several Shape3Ds or does it make the "downsampling" itself ?

It is discrete LOD. So it needs several Nodes (could be whole Models).

Creating a continuous LOD calculator there's much more to do. Much more complicated math. But maybe it's already done in one of the model loaders. I don't remember which, but I think I saw something about LOD in one of them (I think it was Cal3D). Maybe the LOD is coming from the Model format. But if not, I could try to generalize the LOD code.

Marvin

['n ddrylliog]

It needs several Shape3Ds or does it make the "downsampling" itself ?

It is discrete LOD. So it needs several Nodes (could be whole Models).

Creating a continuous LOD calculator there's much more to do. Much more complicated math. But maybe it's already done in one of the model loaders. I don't remember which, but I think I saw something about LOD in one of them (I think it was Cal3D). Maybe the LOD is coming from the Model format. But if not, I could try to generalize the LOD code.

My opinion :
- Generalizing the Cal3D code will be hard
- Continuous LOD isn't really used those days, discrete LOD is preferred, so it's not an important feature..

[Marvin Fröhlich]

My opinion :
- Generalizing the Cal3D code will be hard
- Continuous LOD isn't really used those days, discrete LOD is preferred, so it's not an important feature..

OK, agreed.

[Patheros]

- Continuous LOD isn't really used those days, discrete LOD is preferred, so it's not an important feature..

Isn't there a Morph node that might be suitable for continuous LOD if someone wanted it?

['n ddrylliog]

Isn't there a Morph node that might be suitable for continuous LOD if someone wanted it?

Yeah but IIRC, the Morph node works only with geometries having the same vertice count.