I had to change my zoomingcode for ortho. So instead of manipulating the frustum (which leads to a matrix not invertable exception when picking and being zoomed out a lot) I now have to manipulate the scale of the scene.
Works like a charm with the exception of physics.
The following code shows what I am doing after updating (sorry, I threw in almost all update calls I could find).
getRootNode().setLocalScale(scale);
getRootNode().updateGeometricState(0.0f, true);
getRootNode().updateWorldData(0f);
getRootNode().updateWorldVectors();
The problem is that the more I zoom in the slower the material gets (I have a conveyor material that moves boxes around) and the further I zoom out the faster it gets.
I guess the force vector is not adjusted as I expect it.
Is that intended, is there a way around this?
pflanzenmoerder said:
Is that intended
yes
The speed of the material is in 'distance unit' per 'time unit'. So scaling up the sizes means to relatively slow down all the speeds. You'll notice the same for things turning / falling etc. as inertia vectors would (have to be) change(d) as well.
From the top of my head I'd say you would need to scale gravity, all densities, all speed values, all forces and joint accelerations (all of them linearly?). So in essence: don't scale your scene for zooming, if you use physics! :|
Haha, nice 8)
That means I am screwed. We are using ortho mode for display and there zooming without scaling the scene fails for the above reasons (posted this in the trouble board).
So I guess I will have to do exactly what you said:
Find all values and change them by hand aaaaaaaaaaaaaargh
I’ll have a look into that thread. You’re talking about this one, I suppose.
Thanks a lot.
Yes that's the thread I was talking about.
I am happy about any hint you can give for zooming in ortho.
Right now I don't see an alternative to scaling.
I think I must be missing something but anyway: wouldn't this be solved if you change the frustrum instead of scaling the level to zoom in / out?
That's what I did before and that's what the other thread mentioned above talks about.
To make it short:
Being zoomed out a lot by changing the frustum breaks the current picking code.
Oh I see. Thank you for explaining.
Maybe you could scale statically just a couple of times, and that would be enough for you to zoom out. However this will alter all your physic constants.
About the matrix inversion issue, I have no idea… that's for the hardcore mathematic guys. However, it doesn't seem that jME cares about float precission at any other point in the API.
Take a look in the other thread. I replaced FLT_EPSILON with 0 and now frustum based zooming works.
I don't know if this will help, but ChaseCamera has zooming, maybe you could use it if you disabled rotation from it. I don't know exactly how that would work.
ChaseCamera does distance based zooming (at least from what I remember) and is therefore not suitable for ortho mode.
As I said before: zooming works, you just can't zoom out far enough without breaking the picking code.
It's fixed in my implementation and as Irrisor suggested I made a suggestion to the developers to change the offending part of the code in JME.
