Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[slibenli]

Yes I use GLM. I'll take a look at it.

What helps is applying the translation and the rotation matrix one after another in the shader. Camera movement is still choppy, but the mesh doesn't wobble anymore.

[slibenli]

I fixed it. Using glm::lookAt to generate the view matrix didn't help though - it was really a floating point precision issue as I suspected.
My mistake was to pass the model->world and world->view matrices to the shader separately and multiply them in the shader.
I think the reason for doing this was to save one matrix multiplication on the CPU.
When I  calculate the model->view matrix on the CPU using double precision the problem goes away.

BTW - This is what I meant with wobbly meshes (1000km from origin):

[Stainless]

Oh wow!

I have never seen that before. It seems something is wrong with the matrix multiply.

The rotation part of the matrix should be very resilient to floating point issues as we are only dealing with numbers between -1 and 1

And the rotation part MUST be totally independant of translation. If you find the meshes are rotating in any plane as you move them away from the origin then something is VERY VERY wrong

Is the code online anywhere? I think I need to have a look

[Stainless]

I have been thinking about it, and the only thing I can think of is a matrix ordering problem.

Basically matrices come in two types, row major and column major. This only affects which order the values are stored in memory.

But you are loading matrices from HIM files so there is the possibility you are loading a matrix incorrectly.

The only way I can think of to get the results you are seeing is if the location matrix you load from the HIM file is in the wrong matrix order, but I would have thought everything would be screwed if that is the case.

If your "fix" of doing a matrix multiply yourself solves the issue, it may be because you have changed the matrix order in the multiply. Hmm I wonder if that is the root cause.

Matrix1 * Matrix2  is not equal to Matrix2 * Matrix1

I should look at the code

[slibenli]

The fix: https://gitlab.com/vrresto/il2ge-experimental/-/commit/2a91fc7ac617b4e9536aaf9a3198bc36e9404228?view=parallel

I can rule out a problem with the matrices from HIM files. Not applying these yields the same results.
I would expect that when messing up the multiplication order the results would be way more off (in fact this happened before).
As I see it the issue was with the translation part. If camera and mesh are far from the origin both model->world and world->view will contain high translation values.
In the resulting model->world matrix the translation values would be low again (for meshes that are close to the camera).

[Stainless]

Since you are doing the matrix multiply in the shader, I would use the highp statement

The problem you are talking about makes no sense to me and just should not be possible if the matrices are created correctly

I would change the code to to something like

Code: [Select]

uniform highp mat4 model_view;
and set it with

Code: [Select]

     GLuint MatrixID = glGetUniformLocation(programID, "model_view");
     glUniformMatrix4fv(MatrixID, 1, GL_FALSE, &model_view[0][0]);


[slibenli]

highp is only relevant for OpenGL ES.
Maybe it's a driver bug that somehow causes low precision.
Avoiding world space coordinates in the shader is a good practice anyway, so I'm gonna leave it as that.

[slibenli]

I'm wondering how to render trees (the non-collidable type).
Correct me if I'm wrong, but from what I can tell the tree meshes they are not loaded from files but created programmatically.

So that would mean I would have to come up with an own.
Or use available tools/libraries for that. Something like this:



But I'm looking for something simpler - the IL2 trees are basically just a stem and a bunch of sprites around it.
At least it should have the option to generate such simple models for lower LODs.

[Stainless]

Low LODS should be incredibly simple, 4 - 6 triangles.

You probably already have this.

Mid LODS look best as simple meshes and obviously if you have a need, the closest LODS need a lot of work.

LSytems are the best way to GENERATE trees. Setup some rules and grow a bunch of trees that all look like a single species but are different from each other.

( the rules define the species , but have randomness in them )

I never do this realtime though, I always do it offline and save the generated trees as meshes

https://github.com/paluka/L-Systems-OpenGL
https://github.com/abiusx/L3D

Good starting points


 

[slibenli]

Thanks, I'll look into these.

[th12333]

How are you?

[vonOben]

Hi slibenli

Great work with the Graphics Extender, many thanks!   

 

Does also older builds of Graphics Extender require OpenGL 4.5?

The older readme's doesn't say anything about it.

I'm using the latest driver for my video card and it has only OpenGL 4.4 support. 

Best regards

vonOben