A minimalist rendering library.

[Julio Jerez]

This continues the discussion on the rendering API.

After researching the possibility of adopting a third-party rendering library, I’ve concluded there isn’t really a good solution.
Every candidate comes with numerous constraints, and most suffer from the same limitations you face when working directly with the low-level APIs.

About twenty years ago, I relied on GLUT, based on the promise of broad, long-term support across platforms. For a few years, that was true, until tech companies began redefining what OpenGL was supposed to be.
With the arrival of OpenGL ES for mobile, GLUT became practically useless on those devices unless you resorted to awkward workarounds and specialized variants like GLW.
Over time, things simply stopped working.

Since then, we’ve seen an explosion of new APIs: Vulkan, Molten, Metal, DX12, NVIDIA’s various libraries, and more, each making true cross-platform support increasingly difficult to maintain.

My conclusion is to build a lightweight rendering library, inspired by what RenderWare used to be. The goal isn’t to create a full rendering engine, but to provide a consistent cross-platform backend. This approach will also help clean up the demos, removing low-level API calls that can confuse users, while offering a path to improved basic rendering quality for teh demos.

[Julio Jerez]

The library now get to a slow part. That I hate the most.
The combinatorial effect of vertex shader/pixel shader
And shader parameters.

I miss the old day of the fix pipe line. Now you get this
Problem that for each shader with a different set of parameter, you have to generate the difference combination

This is really a pathological side effect of that method
I have seen engine like unreal generation several gigabyte files of compiled shaders, that need to be preloaded in GPU
Before you start.
Building the shader cache takes over 24 hour in a very fast PC.
My method will just be at the primitive level.just like renderware was.
Yes is not that powerful, but good enough for demos.
Even that simple system requires carefully implementation consideration, other wise it gets very messy really fast.

[Julio Jerez]

it now has all of the feature that the old method had and a lot more.
new features are:
the scene has environment reflection, and instance rendering cast and receive shadows.

as a side not. I was plaining to have instance before adding the demos.
but then I remembered how slow it becomes when you render few thousand primitives.
so I added instancing.

there is one only small problem, the passes increase quadratically with the number of features.
so adding instancing generation shadow, do take a tall in rendering.
the fps is still in the 2k fps from almost 7 thousand.
without instancing, believe or not, rendering become slower that the physics update.

one improvement that I can make is adding a rendering to texture pass, that the environment with a filter of the reflection instances. and rendered to a lower (512 by 512) cube map,
that will generate a one level dynamics reflection. and should not be too expensive.

The secund feature is alpha blend for population the map lot of stuff like trees and grass or object with detail parts that I always have to edit out form models.

anyway, that's for the future, now I will add scene that use instancing

[Julio Jerez]

I’ve expanded on both the graphics system and the demos.

Graphics:
-Improved the Blinn reflection model so objects now render with better visual quality.
(Reflections between objects are still pending and set as a lower priority.)

-added some camera functionality, that allow for attaching to a scene node.
this make is a lot simpler to add different camera modes, by just make special nodes that
calculate the transform is some specific ways, while the camera is just a simple object that
does not change.

-Added an FBX loader that generates proper materials for imported files.
FBX files are first loaded into Newton’s intermediate ndMesh format, which is then converted into the ndRender library format. This makes it possible for anyone to load FBX files and convert them into their own game library formats. The demos serve as practical examples of how to do this.

ndMesh now supports an export mode. Currently, it outputs ASCII, but XML export will be added later.

Demos:
The latest demo now features a prop placed in the terrain. I cleaned it up since years of user modifications had made it confusing. The original version came from a European company that specialized in large-scale vehicle simulations, populating scenes with hundreds of vehicles.

The demo now takes advantage of new functionality in Newton 4.xx, making it far more efficient and overall, in my opinion, the results are quite practical for population game with dynamic props.

for the next demo I will make a ndModel for object placement.
one that will also take advantage of the new newton feature.
from now on almost all demos will capitalize in ndModels.

[JoshKlint]

This might be what you are looking for. It was made by the author of Blitz3D:
https://github.com/blitz-research/libsgd

[Julio Jerez]

Oh wow, I wish I had come across that earlier when I was searching.
I’ve been looking for something like this for years, but everything I found before was an absolute monstrosity.

Back in the ’90s when I started out, the main graphics APIs on PC were RenderMorphics
and Open Inventor, for high end no real time rendering packages like Softimage and 3D Studio.
I really liked Open Inventor, but it was just too slow for games.
Later I found OpenSceneGraph, which felt like a stripped-down version of Open Inventor, so I gave it a try. Unfortunately, it quickly became cumbersome and hard for most people to use. That’s what pushed me to stick with native OpenGL, and the rest is history.

The big problem, though, is that it’s strictly OpenGL, which makes it a non-starter for platforms like macOS or mobile devices with their many different OpenGL variants. Another issue I’ve always had with these libraries is that they tend to take over your whole application. Suddenly you’re buried in dependencies, build settings, and configuration headaches. What I was really looking for was something lightweight, like GLUT, but those days are long gone.

What I like about this library is that it seems lightweight, cross-platform, and even more complete than the current successor to OpenSceneGraph. It seems like exactly what I was looking for

Now I see two possible paths:
1-Abandon the work I’ve already put into my own library and switch to this one.
2-Continue building my library, which still has a long way to go.

For now, I’ll stick with option two. Once I get to the macOS port, I’ll reevaluate.
Keep in mind, I’m not building a video game, just demos to showcase Newton features,
so I can always stop whenever I want.

Thanks for the link, I’ll definitely check it out.

[JoshKlint]

Mac still supports OpenGL 4.1. New ARM Macs being sold today support OpenGL. They do everything they can to discourage you from using it, but I don't think they'll ever be able to get rid of it because there is too much legacy software that relies on it.

After a disastrous experience with Vulkan, I switched back to OpenGL, and I plan on using it for Mac builds of our software. The tech industry is moving backwards and OpenGL is still the best API we've got.

[Julio Jerez]

Umm, it is a really bad idea to go with a deprecated feature.
Specially with Apple.
Five years ago, I was working on AAA port of a game to IOS.
Almost device support had to be rewritten.
I was task with the sound system.

After month and month of trying to Carter Apple sound support, I concluded that it would be better to go with another library.
So it came to a choice between fmod and openal.
FMod has licensing issues.
And openAL was deprecated for IOS. But you could still get the framework after installing homebrew.
So we went with OpenAL.
Everything was going well until we got to certification.
Guess what, Apple refused to approve certification because we're using deprecated frameworks.
That translated to loss of money.

a deprecated framework means it will support existing applications; it will not be approved for new application.
OpenGl in all its forms, is deprecated by apple, so I would not invest on that for a new app.

[Julio Jerez]

When it comes to Vulkan, you don’t need to convince me it’s a mess,
I figured that out the first time I tried it years ago and the various time and try after.

At its core, Vulkan only really adds the ability to create multiple queues so an application can dispatch commands in parallel. But it does so at the cost of enormous overhead and complexity.
Sure, it’s “low level” and might appeal to elite graphics experts, but the idea that you need to be a top tier programmer just to get anything working is absurd.
The reality is that the chances of making catastrophic mistakes in Vulkan by a graphic programmer, are far higher than in a driver maker imposing some restrictions, and to make even worse, the API itself feels poorly designed which also contribute to make the huge mistakes, drivers are buggy, and even on the same platform, GPUs behave inconsistently.

Take memory management as an example. Vulkan makes a big deal about its memory pools, but the design is clumsy: when you create an object, you have to specify a pool, and on destruction you’re expected to remember which pool you used. The API doesn’t let you query the object for that information, it’s just sloppy. And that’s not even touching the nightmare that is synchronization and the several hundred of Layer that does not seems to help at all.

Other modern graphics APIs manage to offer everything Vulkan does, but in a much simpler and often more efficient way. In fact, they consistently outperform Vulkan in the very areas it claims to excel: performance and efficiency.

In my view, Vulkan is only viable for massive studios with massive budgets. For indies, it’s a time sink with little payoff, mostly because Vulkan isn’t a primary target for most tech companies. Big vendors only keep their Vulkan drivers minimally compliant so they can avoid backlash, not because they care about making it a first-class option.

[JoshKlint]

If Apple drops OpenGL support, we just won't support Mac. They have half the market share of Linux now.

[Julio Jerez]

You might be right that it’s still supported, but just last month I tried building the engine on macOS in my Mac Mini, and I ran into problems. I couldn’t find GLW in any of Apple’s frameworks.
When you check Apple’s support sites, it clearly states that OpenGL is deprecated:
https://developer.apple.com/library/arc ... intro.html

Maybe you’re right and there’s something new I don’t know about,
so don’t just take my word for it, do your own research.
I’ve also come across a lot of conflicting opinions, but what they all seem to agree on is that you need to install Homebrew, which is a non-starter for end users.

Believe me, I’d be thrilled to get the engine running in macOS with OpenGL, but so far, I haven’t been able to. On top of that, I couldn’t find a working framework for the OpenGL loader, and the opensource ones, I tried, wouldn’t even compile.
They made it really hard to get a work around the deprecation, this is simply because Apple is so closed that the only way to worth with the low level is via a system framework.

[Julio Jerez]

Continuing the Work
I’ve just added a complete mini-level map, and it now includes some of the core elements you’d expect in a game:

-A few players (both PC and NPC)
-A multi-geometry mini-map
-Dynamic objects that players can walk and stand on
-Everything interacts physically with everything else, and the entire script is still under 400 lines of code.

Of course, all of this is still programmer art, so it could definitely use some visual polish.
But it’s already enough to demonstrate how to integrate Newton into a game engine.

The next set of demos will expand on this one by introducing a map with vehicles that players can possess and drive.

[Dave Gravel]

Hi Julio,
Just to let you know, I tried your new demo and it's awesome.
In what I tested, everything seemed correct and working well.
I did get one error with the player character once, but I think it was a debug assert,
I'll need to retest it later.
As for the new graphical implementation in the demo, that's awesome too,
I really like it.

I updated my latest engine that uses Newton with the latest SDK updates.
But since it's been a while since I last updated,
I'm having some issues with the notify userdata and a few parts in the ndModel.
I'll try to get everything updated in the coming days.
I don't have as much time as I used to, but I still love testing and trying new things.

And I'd like to continue my motocross project. But for now,
I need to find and apply all the updates that have happened in Newton so it starts working again,
and refresh my memory on a few parts of my engine and Newton.

I'll see, if I don't have enough time to fix things in my engine,
I might use the Newton SDK demo to make a new version.
But as always, when winter comes, I usually have more time.
For now, though, this message is mostly just to say hi and tell you that the new changes are awesome, I like them a lot, and everything compiled fine here.

[Julio Jerez]

Oh wow, it’s been a long time since I heard from you, great to see you checking it out!

yes, there could be some asserts, I am still covering the basics functionality.
I think I got to a stable point now.
I you get another, please let my know about.

Yes, the notifications can definitely be confusing, even more so now.
One thing that helps clarify it is understanding that two types of objects can have notifications: ndRigidBodies and ndModels.

When you’re working with a model, you typically go through the model updates, grab the bodies you’re interested in, and from there you get the body notifications.
It takes a bit more code, but once you get the idea it actually feels more object-oriented.

I still want to continue my motocross project, but for now…

In this latest SDK I’ve added a lot of features. The most important one is that skeleton joints are now solved using a preconditioned LCP solver. This fixes one of the major issues with long chains that include loops and contacts, the solver now converges almost every time and very much quickly.

That said, there is one caveat: the preconditioned solver isn’t as smooth. It solves each row very quickly, but because it doesn’t always distribute enough iterations across the system, the error in other joints can end up being larger compared to a regular Gauss-Seidel approach.
This is very similar to what happened in version 1.xx.

In practice, though, it’s a rare issue, you’ll barely notice it outside of edge cases.
For example, I only spotted it in the roller coaster demo.
Later I may add an option for a “looser solve” or something along those lines, but for now I’ve just left it out of the demos.

Th either big improvement I made is the adaptive thread dispatcher.
when I made the thread pool, the CPU what two, for or six cores.
at that number of hardware core, dispatching jobs to a thread is not a big deal.
however ever with the increase of core count, this becoming a high fix cost time consuming operation.

image you have 32 threads, and your scene is very small,
the cost of running with all the tread was significant slower that just launching with one thread.

for address that I made the thread dispatcher adaptive. similar to how GPU enqueue kernels.
basically, the invocation passes the number of jobs in advance, and the dispatcher determine how many cores are needed.
This has the effect that setting a high thread count does is no slower, and also the CPU run a lot less so it consumes less power.
It also good for the new Bit/Small cores systems. because by dispatching the low core more frequently, the OS can designate Big Cores to the task more than randomly selecting cores.
seem to work much better.