A minimalist rendering library.

[JoeJ]

My gravity problem was because the model update function signature has changed (in the notify, now not taking the world as param). Easy to fix and now everything is working.
But i wonder if there is a way to trigger compiler errors in this case?

Here my fixed code:

Code: Select all

class ModelNotify : public ndModelNotify
{
//...

      void Update (/*ndWorld* const world, */ndFloat32 timestep)
      {
         model->Update(GetModel()->GetWorld(), timestep);
      }
};


Would i get an error if i would add some 'virtual' in front of the void, or something like that?

I should not really ask such C++ beginner questions here, but feel free to help an OOP noob out
I think there really should be a way to make clear that i want to provide an implementation of a certain virtual function. It's not the first time simple signature changes break my stuff, and ther should be at least compiler warnings.

Regarding depth bias, i have never learned to use it. Reading the specs left me with confusion on what those API features exactly do. But iirc, there are two different forms of bias, both with their own related tools on the API side. Maybe one for a slope bias (acne) and the other for a constant offset (peter panning), but idk.

Personally i could fix acne by creating a plane from the shading normal and projecting my samples to that plane. So that's a form of slope bias i guess. The fix creates a discontinuity due to plane flipping cases, but it's in shadow and thus not visible. But i use a crazy expensive 4x4 region of samples. Only this way i could hide visible SM texels and fix all artifacts (acne, panning, and VSM leaks).

Yes, i did it! My shadows are practically free of all those known artifacts! It's possible! \:D/
But by getting there, i have also discovered new artifacts. They really are not bad, and i could call them 'high end artifacts'. But it's still artifacts.


For the sky i want a procedural model, like this for example: https://www.shadertoy.com/view/slSXRW
But i hope there are simpler models to find.

[Julio Jerez]

For virtual functions, yes there is a way to make the compiler warn you if the signature of a virtual function on a sub class is incorrect.
Unfortunately it an optional cpp 17, I think option,
You just add the keyword override at the end of the function in the derived class.
I have being trying to do it in the SDK, every time I could.
Apple clang is good at warning that.

The zbias, in shadow, there are essentially two methods.
One: you set the bias when generating the shadow maps, which is the method I am using because I find more reliably. Since the hardware supposedly does it at the rasterization stage, considering the face normal of each triangle.
This is supposed to be the most sophisticated method, because consider the triangle inclination to generate a variable bias in the sgadowmap buffer.
But you are right, it is a black magic art, that has never being well documented, and in fact can change from GPU to GPU.

The second option is to do it yourself when rendering the mesh from the camera, by reading the shadow pixel and offseting in a variable in the pixel shader.
This method, you are in control, because to know all the parameters.
But so far in all my experimentations, I found worse to tune.
The reason is that you do not know the slope of triangle the pixel in the shadow maps texture.

Anyway, as I said before, I think my problem is that I am setting the bias, as a const for all shadow maps.
And that not current.
For example.
A pixel in shadow, that happens to be in the shadow closer to the eye point, had an enormous z buffer resolution, basically a depth value cover a few meters.
So here the bias has to be very big, like 30,000 or so.

As the cascade zone move away from the camera I point, the pixel cover more distance, so each pixel in shadow get less resolution. Therefore the bias should be smaller.

A naive way is to just multiply 0.5 for each unit, map as the are farther away.
Buy the maps din exactly cover twice the distance, the distance are usually set by hand,
I am using an exponential heuristic.
Si I will add the calculation of the bias there.

The true answer is that the only way to get good shadow is ray tracing

[Julio Jerez]

I think I have a better setting now, I move the bias setting to the inner loop on the shadow pap rendering passes.

Code: Select all

         glViewport(vp_x, vp_y, m_width, m_height);
         glPolygonOffset(GLfloat(1.0f), GLfloat(zbias));
         for (ndList<ndSharedPtr<ndRenderSceneNode>>::ndNode* node = scene.GetFirst(); node; node = node->GetNext())
         {
            ndRenderSceneNode* const sceneNode = *node->GetInfo();
            sceneNode->Render(owner, lightSpaceMatrix, modepass);
         }
         zbias *= ndReal(2.0f);


This makes it a lot better, but it is not perfect. THer will be flick at very shaper angles.
anyway, and continue the I will hold on this ndMesh export import, so that I can make a blender plugin that can read and write meshes.

I have a unit that can read fbx file using the Autodesk dll, but the files are fbx, and I can onle load the in my 2012 version of 3dxmax.
I have to use that tool to convert some fpx files, before I can load them int max, or else Max just crashes. and for some the hierarchy in blender is all screwup.
I think having a transport format can help fix that problem. plus allow manual minor editing

[Dave Gravel]

I tested the latest SDK, and yes, it looks better with less flickering.
I noticed only one possible issue, the reflection on the floor.
When I rotate the camera, the reflection rotates too, which looks a bit strange.

off-topic:
I updated my code for the multibody monster truck, and everything seems to work as before, very cool!
You can see it at 10:52 in the video:
https://www.youtube.com/watch?v=iAuK_kQAMbs

I also updated my old raycast car demo. This one works pretty well too, but I still have a few things to fix regarding the friction.

[Julio Jerez]

I tested the latest SDK, and yes, it looks better with less flickering.

I just committed that last tweak for that. I end up making a hard coded look up table for the bias settings. It is the best I got so far, the bridge does show flicker, and it discriminate
the overlapping shadow pixels better. I guess that it will probably fail on smaller meshes, but so fat I think this is good enough.

I noticed only one possible issue, the reflection on the floor.
When I rotate the camera, the reflection rotates too, which looks a bit strange.

I will check that out.

off-topic:
I updated my code for the multibody monster truck, and everything seems to work as before, very cool!

I saw it, it's cool.

[Julio Jerez]

oh yeah!!! you are right, the reflection is attached to the camera.

There have to be a wrong reflection matrix somewhere. I will check it out

Oh I see the problem.
The reflection vector is calculated in the camera space, but if it sample the cube map with that direction them reflect are in cam space, I need to rotate the final direction of the world space before sampling the cube map, it should be an easy fix.

[Julio Jerez]

ahh, I have working for one of the three shaders. Nee to apply it to the other two.
Now reflection on background objects, make sense.
Thank to point that out.

edit: ok I completed all the shaders, that do reflection.
some demos the reflection actually look very nice for such simple render library.
The T pot, which material from Max, is not bad at all.

anyway now, to continue with the xml export/inport for the blender plug int

[Dave Gravel]

Now reflection on background objects, make sense.

Yes, it’s looking better now.
It looks very good in the vehicle floor demo and in the player floor demo, nice work!

[JoeJ]

That's very useful infos on c++ and SMs, thanks!

The true answer is that the only way to get good shadow is ray tracing

Yes, if you can effort to take a lot of samples.
But considering gaming already became a hobby for top earners only, i really think they pushed it too early.

So far i made it to a robust walking speed of 0.75 m/s.
More than twice the speed than initially, but i still need to double it to call it a success.
The problem is, i never see what's the problem and what i should improve.
I will probably move my focus from legs to pelvis and spine, which currently is still just stiff.
Maybe i gain some insights by random luck while doing so.

But i saw that real world robots can not reach running speed of humans either.
So this really seems a hard problem, which i did not expect at all.

But one day my ragdolls will overtake your cars and motorcycles on the highway like in the Supercop movie....

[Julio Jerez]

But one day my ragdolls will overtake your cars and motorcycles on the highway like in the Supercop movie....

or the T1000, advance prototype, Mimetic poly alloy, Liquid metal

[Julio Jerez]

Moving on to the File Importer/Exporter
I now have enough groundwork to start working on the file import/export system.

One thing I’ve realized is that creating physics content is surprisingly difficult for most people — even simple setups can become frustrating. I initially tried adopting the FBX format, but that turned out to be much more complicated than expected.

While FBX technically supports user data in its specification (so you can embed custom information), in practice, very few graphics tools actually make use of it, MotionBuilder might be the only one that does. On top of that, FBX files tend to vary from one software package to another, which makes the format unreliable for consistent data exchange. At best, FBX is useful for transferring raw graphical assets, and that’s about it.

Because of this, I plan to create a simple, graphics-agnostic file format that works cleanly with Blender for importing and exporting assets used by the engine.
This will allow users to author models more easily while keeping the process straightforward.

Initially, the format will stay very simple. Later, these models will be integrated into the ndModel library as archetypes. From there, a game engine could load them directly with physics already set up, and then translate the meshes to its own graphics system.

For now, I’ll be using Blender as the primary tool, it’s free, powerful, and the most accessible option for everyone.

[Julio Jerez]

Wow, another surprise.
About 10 years ago, there was a nice build option to make Blend plugins from visual studio
It seems the blender people, cut all c++ support for making add ons.
Now there is not visual studio support at all, and everything is Python .

You can't even make an add on manually, since the setup process is hideous.

It seems the only option is using visual studio code.
The world is changing at a very fast


I am now ready to write a blender add on that I can use to import and export asset to the SDK.

I am hoping this reduced the huge issues I have with blender/max differences in the fbx format.
Also I need the format to support physics properties, something that turn out impossible with fbx tools.
Simply because the information isn't preserved.