Use of .dds textures

[Noiecity]

I plan to use .dds textures since they weigh less in vram, I plan to create a texture producing its own mipmaps, but I don't know how compatible irrlicht is with this, and if it is, if it will overwrite my mipmaps.

I plan to create 256x256 textures for angles around an object based on the render produced by Blender, so that it looks exactly as the render does, about 8 textures per frame (covering a horizontal angle each, ignoring vertical angles, for example, only covering front, back, left and right sides, etc.).

Render to texture from Blender to irrlicht, irrEdit(only 1 angle, the front):
https://youtu.be/kc_2WvQxQlI

Finally I'm going to add a transition effect between the frames using low resolution renders and SSE2.
I will render a frame and not show it, I will render the next frame and not show it either, I will make a transition between the first frame and the second frame of about 4 or 8 frames, interpolating its opacity as a linear mix... this way I will always have 1 frame delayed but I would have a smooth transition, realistic graphics with a retro style, with a trilinear filter that softens the pixelization.

I don't know if you can interpolate similar to a transition without having to resort to sse2, with the d3d9 or opengl pipeline, in irrlicht.

I think that with this method I could get these graphics, in realtime in irrlicht, in a low-end computer running very well, in high FPS:


(It's an old render that I made in Blender, I lowered the resolution and scaled it with a bilinear filter, similar to what I would do in irrlicht).

In modern versions of Blender you can create a bake based on the camera angle, that is, how the camera sees it, it looks the same as the render... the problem arises if you see the static texture from another angle, it loses realism, so having the model rendered from various angles solves this problem.

Maybe irrlicht already makes optimizations to load the texture in a compressed manner in vram, I don't know, whatever the case may be, what I'm looking for is that, saving space in vram, but it may not be necessary since 256x256 textures weigh very little...

[CuteAlien]

I think Nadro added some support for loading compressed .dds textures in Irrlicht trunk (after Irrlicht 1.8). So in theory that should work. But I've never used that... so can't tell more than that in theory support for it is there.

[Noiecity]

I think Nadro added some support for loading compressed .dds textures in Irrlicht trunk (after Irrlicht 1.. So in theory that should work. But I've never used that... so can't tell more than that in theory support for it is there.

Thanks, I just saw this in the change notes:

- Improved DDS loader and added support for DXTn (DXT1-5) compressed textures in OpenGL and Direct3D9 drivers.

viewtopic.php?p=299727

I also saw that in an old answer you gave you talked about the texture limit, is this at the material level?

[CuteAlien]

Texture limit is a bit complicated topic.

Originally this came from a very old OpenGL (or maybe D3d?) version. I think at some point 20 years ago or so fixed function pipelines only guaranteed 4 textures (not finding this info anymore, but I'm sure I read about it once). Which I guess is the reason why Irrlicht used 4 textures in SMaterial.

At some point after Irrlicht 1.8 (and before I knew about the reason for this limit to 4) I raised that number to 8. Just did that as people requested it a lot and I also could use it (unknown to me 8 also seems to be the WebGL1 limit). But then I noticed raising this number to 8 had some speed affect, so I allowed users to reduce it again via irr::video::MATERIAL_MAX_TEXTURES_USED (you can set this at runtime to a lower number at program start if you don't need 8 textures and it can make your application a bit faster).

And well... 8 per material is better and usually enough for meshbuffers. But there is another thing which Irrlicht has no support for. And that gets _a lot_ in the way when shader coding: Graphic cards support way more active texture units these days (can be over 100). And those are often not changed per meshbuffer - but stay intact as global textures. Stuff like environment maps, shadows maps, random textures, etc. And global textures simply don't exist in Irrlicht. It's still possible to use them in OpenGL directly, but one often has to work a bit against Irrlicht for that. Because there is always only 1 "active" texture for most commands. And Irrlicht likes to control that (keeps internal cache with the info which one is active because the corresponding gl functions are slow). So you can set another texture active outside of Irrlicht with OpenGL, but Irrlicht might then not realize next time it works with an internal texture that it's not longer active because it didn't get informed about what the user did in GL. There are some really ugly workarounds for that (which I'm using myself...), but this is maybe right now one of the biggest downsides of the current Irrlicht engine. I hope I can at least make the workaround a bit easier over the summer.

[Noiecity]

Ok, but I can use more textures as long as they are not active at the same time, that is, replace the one that is active with another one. Currently graphics cards, well, since 2003 or so, force the use of float point for almost everything and ignore fixed point type optimizations, I don't know if it's relevant but it's interesting... (fixed point was actually faster for low resolution textures, although the graphics were shaky like on ps1), like Nvidia RIVA 128, Dfx Voodoo Graphicsm, etc:

min 17:13
https://m.youtube.com/watch?v=jjbqfmbs6Q8

[CuteAlien]

Fixed function pipeline is not about float vs integers, that's another topic ;-) (and funny enough a topic I worked on last 2 weeks, turns out getting .hdr and .exr floating point formats working with Irrlicht was pretty trivial, I might post that code in the future).

It's fixed function pipeline vs shaders. Fixed function as in - you only had few fixed functions to combine textures. So you could say multiply texture 1 with texture 2 or add texture 1 to textures 2 or use one as mask for other and so on. While this day you can run real code (shaders) on the gpu which can do whatever it wants (well within some limits). That was also why you didn't really need so many textures with the fixed function pipeline - you couldn't do any complicated math on them anyway and there's only so much you can do with a simple set of operators combining them.

[Noiecity]

Fixed function pipeline is not about float vs integers, that's another topic (and funny enough a topic I worked on last 2 weeks, turns out getting .hdr and .exr floating point formats working with Irrlicht was pretty trivial, I might post that code in the future).

It's fixed function pipeline vs shaders. Fixed function as in - you only had few fixed functions to combine textures. So you could say multiply texture 1 with texture 2 or add texture 1 to textures 2 or use one as mask for other and so on. While this day you can run real code (shaders) on the gpu which can do whatever it wants (well within some limits). That was also why you didn't really need so many textures with the fixed function pipeline - you couldn't do any complicated math on them anyway and there's only so much you can do with a simple set of operators combining them.

Thanks, I will consider that to see the results later (mixing with the techniques you mentioned). I don't usually write shaders since I usually ruin the pipeline by default... I'm too clumsy to do anything useful so...
Regarding fixed point, although I know it has nothing to do with this, I mention it to clarify some doubts, it is only used if vectorization can be achieved, on CPUs with SSE2 for example, on development boards with an ARM processor you can use Neon... this is only usable in this way since otherwise, when trying to multiply int8 with another int8, you do not get a real advantage over floating point... the same thing happens with the GPU, it is only used if the GPU is optimized for parallel calculation with these data, such as graphics cards with integrated NPUs...
https://oriwhiz.com/products/luckfox-pi ... uch-screen

or Horizon Robotics X3 Pi, etc...

Sorry, I go off the beaten path and talk about unrelated topics...

: D

[Noiecity]

Perfect, the best way is to have even smaller textures, such as 128x128, and simply create a camera projection type uvmap, render and use the same render for that uvmap, I even take advantage of all the pixels of a texture using this method since I do not waste space with parts that are not going to be shown. Now this is just one angle, but here's the cool thing, overwriting the current uvmap is very cheap, even with models with 2000 triangular faces, I can do it hundreds of times and it doesn't affect performance... now, that implies having textures loaded in vram, since each uvmap has its own texture for each angle, but using dds this is extremely cheap, I can have hundreds and it only takes up a few mb in vram (this with dds)...

That is, I can have a model and see it exactly in Blender, although the difference is that in Blender the model is displayed with strong antialiasing, but in Irrlicht this is fixed if render to texture is used with a trilinear filter on the 2d material displayed...

That is, I no longer need shaders, unless it is about showing reflections of an animated model on top of a floor (with static models I can still simulate reflections with the previous uvmap technique). And not only do I no longer need shaders for these cases, it is practically more realistic and cheaper, although it requires more work... exporting each uvmap as an .obj, storing its uvmap in a buffer, etc... more work, for more realism at less cost.

In blender 2.76b, select the model 3d with right click -> press the Tab key -> select all vertices pressing the A key -> Press the U key:






Fotosketcher 1.98 brushstokes filter + softglow Gimp 2.8.22(and more contrast, light and saturation)-> export image and use in the model 3d:



This only works at short distances, since the break point when you rotate until you notice the failure due to baking based on a single angle has more tolerance up close, but from a distance the tolerance is much smaller. It's cool though.

Unless you use it for 3D isometric games, then this is incredibly functional.

At short distances it is tolerable enough to change the uvmap and texture to produce a super realistic effect of reflections and textures. The problem is that you must know how to render a scene realistically (it is not difficult to do it, it may be difficult to learn how to do it)