• June 23, 2021, 08:23:21 PM
• Welcome, Guest

Pages: 1 ... 84 85 86 [87] 88 89 90 91   Go Down

### AuthorTopic: graphics extender  (Read 171917 times)

0 Members and 2 Guests are viewing this topic.

#### slibenli

• member
• Offline
• Posts: 515
##### Re: graphics extender
« Reply #1032 on: June 20, 2020, 10:48:01 AM »

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

• member
• Offline
• Posts: 515
##### Re: graphics extender
« Reply #1033 on: June 23, 2020, 11:19:28 AM »

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

• Modder
• member
• Offline
• Posts: 1484
##### Re: graphics extender
« Reply #1034 on: June 24, 2020, 03:46:12 AM »

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

Logged

#### Stainless

• Modder
• member
• Offline
• Posts: 1484
##### Re: graphics extender
« Reply #1035 on: June 24, 2020, 04:39:00 AM »

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.

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

Logged

#### slibenli

• member
• Offline
• Posts: 515
##### Re: graphics extender
« Reply #1036 on: June 24, 2020, 07:31:01 AM »

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

• Modder
• member
• Offline
• Posts: 1484
##### Re: graphics extender
« Reply #1037 on: June 24, 2020, 12:28:50 PM »

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]);

Logged

#### slibenli

• member
• Offline
• Posts: 515
##### Re: graphics extender
« Reply #1038 on: June 26, 2020, 01:18:57 PM »

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

• member
• Offline
• Posts: 515
##### Re: graphics extender
« Reply #1039 on: June 28, 2020, 05:54:40 AM »

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

• Modder
• member
• Offline
• Posts: 1484
##### Re: graphics extender
« Reply #1040 on: June 28, 2020, 06:37:07 AM »

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

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

Logged

#### slibenli

• member
• Offline
• Posts: 515
##### Re: graphics extender
« Reply #1041 on: June 28, 2020, 08:29:15 AM »

Thanks, I'll look into these.

#### th12333

• member
• Offline
• Posts: 11
##### Re: graphics extender
« Reply #1042 on: August 19, 2020, 08:01:31 AM »

How are you?
Logged

#### vonOben

• Modder
• member
• Offline
• Posts: 623
• Wer den Tod fürchtet, hat das Leben verloren.
##### Re: graphics extender
« Reply #1043 on: August 20, 2020, 04:56:39 AM »

Hi slibenli

Great work with the Graphics Extender, many thanks!

Does also older builds of Graphics Extender require OpenGL 4.5?