Another suggestion: "IVideoDriver::setBeginSceneOptions"

[Mel]

This is a suggestion more in the line of a comment, than an actual request. With regard to the new APIs (Vulkan, Metal, DX12...) All of them seem to have adopted the form of several objects that perform by themselves a subset of the whole operations that the older API could perform on its own changing the states of a "machine". This saves the overhead of the changing states of the older API and their stalls, and speed up things by just keeping these objects in memory, and using them when necesary, allowing also for multithreaded execution.

This also affects how the screen is cleared. In the case of Vulkan, which is known to me, these are both the parameters of a render pass and a drawing command to clear the screen and the depth/stencil buffer into given values. The problem comes from the fact that the render pass is now an object with an entity and an utility that it is not trivial to change, it creates a dependency directly with how the shaders are used (the pipelines) thus, changing them require also recreating the pipelines to some degree and clearing to a value and or disabling those elements on a per frame basis is something that is no longer obtainable without a large amount of work behind that could degrade the rendering eficiency if they were left as they are now. As for the clearing color, Vulkan records the graphics commands into a buffer that can be constantly reused, so changing the clear value would mean that this buffer has to be updated each frame, with the overhead it carries.

Thus my idea that there was a new method for this task, the "setBeginSceneOptions" or the like. Which would still be totally compatible with the current setup of Irrlicht, but that would also help for future upgrades of the engine, if ever.

This method would involve a seris of variables which would hold a clear color value, a stencil and a ZBuffer clear values along with a couple of flags that indicated if the color or the Z/stencil Buffer have to be cleared, and that in the case of change, would trigger the update of the rest of involved elements so the functionality remained as it is now.

[REDDemon]

Sounds good to be implemented along with vulkan/mantle.

[Granyte]

Also currently there is no way to set the value of the zbuffer it always clear to 0.

this would be usefull tor everse the zbuffer

[CuteAlien]

@Granyte: With svn trunk you can set the value for the zbuffer. Also default is 1.

[Granyte]

good to know
however I'm stuck on the FVF for now to many features are missing from the trunk i cannot jump back

[Mel]

Another thing that will need a sure revamp is the material systems, the new API are stateless, now the settings are stored on objects that may change at runtime, thus the materals can no longer be simple structures, or perhaps, they would serve only as a frontend to a more complex "behind the scenes" machinery...

[sunnystormy]

Interesting idea!

Since we're on the topic of multithreaded drawing code, I wanted to know if the software renderers are multithreaded? I'm developing a chip that could take advantage of that parallelization if it were present.

[CuteAlien]

No, there's no multithreading support in Irrlicht.

[sunnystormy]

@CuteAlien

Is this something I would be allowed to add? I could use the C++11 threading library to accomplish this...

The reason for it is because the processor I'm developing has a many-core design that would rely upon parallelized software rendering to handle graphical tasks.

[Granyte]

Another thing that will need a sure revamp is the material systems, the new API are stateless, now the settings are stored on objects that may change at runtime, thus the materals can no longer be simple structures, or perhaps, they would serve only as a frontend to a more complex "behind the scenes" machinery...

wouldn't the new api being stateless actually favor the way the materials currently are ? i mean we simply need a methode to convert from the material class to the draw package from api X

also while irrlicht is not multithreaded the new api are sorta pointless without those so what is the plan?

[Mel]

wouldn't the new api being stateless actually favor the way the materials currently are ? i mean we simply need a methode to convert from the material class to the draw package from api X

That could be a good idea until you hit a fact: the objects you create are meant to be immutable, or at least, to be updated the least possible during the rendering process.

Think of this: Irr materials have 8 textures at most, for instance, and some other settings. the textures could be an object on its own, and the material settings other (there is nothing against that they could be just one large object, but for the sake of the example, let's keep it like this) In Vulkan, the closest example i can think of, i haven't touched neither metal nor DX12, but according to the comments i read and the things i see, it is a similar approach, the procedure is:
-bind this texture set object,
-bind this settings set/uniform buffer object,
-bind this pipeline (aka the shaders),
-bind this vertex buffer,
-bind this index buffer,
-bind this instance buffer,
-issue a draw command.

All these commands have to be recorded ahead of execution, there is no other way. And this is the point. Eventhough you can update the textures and the settings whenever you want, the only change that would prevail would be the last you made just before sending the commands. And recording, executing, changing the constants and then recording again and executing again is a worst idea, because the cost of submitting a command buffer object is high, thus, you want to submit as many commands as you can. The advantage of this whole process is that, being the objects immutable, you only need external synchronization to handle them, you can have multiple threads and a command buffer per thread, and access all of them at the same time, you can change the render of the objects into a jobs system that is processed by these threads in parallel, and have in the end an important set of commands in these command buffers that can be submitted at once. It is even possible to send commands to make the GPU generate those draw commands on its own, perhaps change shaders, perhaps change texture sets... all inside the GPU. But the catch is that the objects have to be read only during the recording process.

So, each material should be either an object on its own, or refer to a much larger structure behind. you can bind 2000 textures at once (I'm not even talking about texture arrays...), for example, so perhaps would be a thing of telling the shader to pick the exact bound buffer via uniforms... I have to experiment more...

irrlicht is not multithreaded the new api are sorta pointless without those so what is the plan?

Irrlicht doesn't have to be thread safe, but there is nothing against building a multithreaded video driver behind You can defer the whole rendering process to the end scene method, and treat each drawing command as just a job submission that returns immediately, even such approach would be a way to create a sort of "thread-safe" irrlicht?.

[sunnystormy]

@Mel

So does that mean that the IVideoDriver class would need to be multithreaded, or the actual drivers (i.e., GL, Software, Burning's, etc.) themselves?

[hendu]

The software drivers are useless, you don't need multithreading for 2d message boxes - their intended use. If you want software rendering, you should use the GL driver and Mesa's llvmpipe.

llvmpipe is natively multithreaded, as well as with support for many instruction set extensions.

[Mel]

So does that mean that the IVideoDriver class would need to be multithreaded, or the actual drivers (i.e., GL, Software, Burning's, etc.) themselves?

None of them. The current drivers may remain as they are. In a nutshell, if you comply with the irrlicht interface, whatever you put behind is a black box to you, you don't need to know how it works, or how many threads it spawns, if any.

[CuteAlien]

The software drivers are useless, you don't need multithreading for 2d message boxes - their intended use. If you want software rendering, you should use the GL driver and Mesa's llvmpipe.

Getting off-topic. But one of the more serious users of Irrlicht uses Software renderer. And the reason why OpenGL doesn't work for them is that OpenGL drivers tend to interpret colors in different ways (which is also why we can't to 100% exact screenshot comparisons for our tests in Irrlicht). While our software driver return the exact same output on each computer.
So useless for some people - but other people are making their living depending on those software drivers.