ground material affects friction, yes. the 1st gif here demonstrates the effect - all tyres are set to have 0.48 mu on tarmac, and 30% less on grass/mud/gravel.
in 2nd gif all tyres have 0.8 mu on tarmac (default value).
in 3rd gif , a constant 48 m/s cross wind acts on an airplane.
there is a friction graph in every gif indicating the ground force on the vehicle (in vehicle axis, top down view)

with gif files, i can show you more interesting things.
this one shows the vehicle drifting, when rear tyres have much lower friction coefficient, any vehicle can do this.


the colored polylines is a tool for testing purpose.

with jpct-ae engine i can easily control the render order of multiple Worlds, very flexible - my app uses dozens of RenderScene calls to render the whole scene. i have to thank Egon for providing this engine and his much support.

i use overrideTexelData at low frequency so it's not a problem for me.
but with FrameBuffer.getPixel i have to convert color format, and at high frequency (to output thousands of jpg files).
so i wish getPixel outputs the correct color format directly.
i mean in jpct-ae .

hope you like these

 

it's not about looking good. it should be used only in special case.
when several operations are organized in different ways, different effects are achieved. having more options is always better. one would not know its use until he encounters the case.

this is not absolutely necessary, but it may provide more flexibility.

i think i will make it releasable in the next year. but not through google or other app stores.

cockpit MFD rendered with RTT techniques

i don't mean using it in shadow mapping, but in other situations.
although i haven't found a use of this , but i think it has special use.

thanks.
i.have multiple rtt textures , but their sizes (some) are different. your way can still save some ram though.
if the pointed vram space is only 1x1 in size, that would be great.

Hi Egon,
i have another question: if a RTT target texture is rendered with depth test off, can the DepthBuffer of this texture be deleted? saving vram is the main concern.

ha, i found the reason.
blitting must have enabled depth test, while the following RTT operation requires depth test off.
i can fix it now.

Hi Egon,
i found a problem caused by blitting into texture - a following render-to-texture (another texture) operation doesn't work.
tested on powerVR6250 and mali450.
i don't know why blitting would affect rendering into another texture, i tried fb.flush() and sync() before setRenderTarget(the other tex), not helping. any ideas?
if i use object3d/overlay to replace blitting, i expect lots of draw calls or complicated programming.

can you pre-create (before  runtime) a 3d model which looks like wireframe of desktop GL?

Hi Egon,
i want some 3d models in main World to be rendered also in another World, and the models in the other World need to be switched from time to time, assuming the meshes are all in GPU, how to switch models?
create new Object3d or call Object3d.setMesh ?
an object3d needs some initialization before rendering, i guess setMesh would be quicker?