4 uv maps for model

[Noiecity]

I have seen that opengl can natively support 4 uvmaps per 3d model, and d3d9 supports up to 8 uvmaps per 3d model, and I believe that opengl supports 4 textures per material and d3d9 8 textures per material, but I am not sure about the latter(in fact I don't know the limitations well, I only know that d3d9 can natively support 8 uvmaps per 3d model).
Anyway, irrlicht natively I think it only supports 2 uvmaps per 3d model, is there a way to increase this value? b3d supports exporting up to 8 uvmaps

Thanks mr cuteAlien

[CuteAlien]

No, this limit comes from the S3DVertex structure Irrlicht is using. It's making it easier for beginner, but is sadly not flexible at all. And it's integrated too deep into the engine to change that. Note that it's pretty rare to need more UV-maps. I was worried about that in the start, but I've still not run in a situation where that was the problem even after all this years I'm using Irrlicht (because most textures tend to share UV's).

The texture limit is way bigger problem actually. The texture limit comes from very, very old API's & hardware. Like for fixed function pipeline in GL only 2 textures had been guaranteed. And hardware 20 years ago usually had 4-8 textures. These days you'll always have at least 16 slots (still not guaranteed for fixed function, but they are there as well - for shaders you have the guarantee). Lot of people asked to raise limit in Irrlicht so at some point I increased the default to 8 (using the define _IRR_MATERIAL_MAX_TEXTURES_ ). But ... I learned soon that this wasn't free, but came with some cost (resetting textures etc - the speed overhead was noticable). So I introduced irr::video::MATERIAL_MAX_TEXTURES_USED - which you can set at the start of the application to go below that number again if you don't need 8 textures (without having to recompile Irrlicht).

But that still leaves many unreachable textures and here things get a bit complicated. Because in most cases you want those textures _not_ per material but global (for stuff like random noise textures, environment maps, etc). And Irrlicht has no support for global textures so far. My current solution is - I work around Irrlicht. Directly using GL functions. Or internal Irrlicht functions like COpenGLDriver::extGlCreateTextures and COpenGLDriver:: extGlTextureStorage3D. Or I bind existing Irrlicht textures to GL texture slots with hacks like this:

Code: Select all

void EffectHandler::bindGLTextureToUnit(unsigned int unit, irr::video::ITexture* texture, bool setMipLinear)
{
	if ( !texture )
		return;

       // super ugly - I directly include "COpenGLDriver.h" in an app to allow for that
	irr::video::COpenGLDriver* gldriver = static_cast<irr::video::COpenGLDriver*>(driver); 
	if ( !gldriver )
		return;

	irr::video::SExposedTextureData exposedTexData = texture->getExposedTextureData();
	GLuint texName = exposedTexData.OpenGL.TextureName;
	//GLboolean isTex = glIsTexture(texName);
	GLenum target = exposedTexData.OpenGL.TextureType;
	gldriver->extGlBindTextures(unit, 1, &texName, &target);
	if ( setMipLinear )
	{
		gldriver->getCacheHandler()->setActiveTexture(GL_TEXTURE0 + unit);
		glTexParameteri(target, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
		glTexParameteri(target, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
		if (gldriver->queryOpenGLFeature(irr::video::COpenGLExtensionHandler::IRR_EXT_texture_filter_anisotropic) || gldriver->Version >= 406)
		{
			glTexParameteri(target, GL_TEXTURE_MAX_ANISOTROPY_EXT, 16);
		}
		gldriver->testGLError(__LINE__);
	}
}

Basically the real problem when mixing GL with internal irrlicht is that Irrlicht trunk introduced a cache for some GL stuff. Including the "active" texture. So you basically either have to use that cache (like I do here) or make sure to reset the active texture slot in GL each time you change it. But as long as you do that and avoid using the textures reserved by Irrlicht you can use higher textures slots directly in GL (at least when working with shaders).

Sorry - this is one of the areas where Irrrlicht has a big problem and solving it is enough work that I simply hack around it myself so far.

And more UV's than 2... I don't even have hacks for that. Just hoping I never run into it (I'd probably switch to raw OpenGL then to pass that).

[Noiecity]

Thanks again, then I'll look more carefully at the code you presented.
Currently using burningsvideo I can store in ram and simply update the current uvmap with this one stored in ram, in fact with d3d9 and opengl I think it only consumes 1 fps so it is quite fast, however for performance reasons, I intended to have 8 uvmaps.
The problem is simple, imagine that you have a sphere, if you render its 8 angles, in an engine that is based on the real light of reality, you get realistic results, now, you can transfer that result to irrlicht if you use a camera angle type UV projection, you get that it looks the same as the render (you use the render directly as the texture of the 3D model).
This is great with 8 angles, for each angle you assign a texture, the transition is not smooth, but it can be solved if you transition textures within the same uvmap (assuming that you use, for example, 64 textures in total, which are somehow in vram for greater performance), you can use that same uv angle to use more textures that cover small angles within this area, and add a transition shader, the result is realistic, you have the render captured in irrlicht, it would be great to transition between uvmaps but I don't know how to do that (that would save me from adding more textures for example).
Irrlicht is so well optimized that the result is surprising, a more realistic result than modern engines, running at 900 fps on a 20-year-old computer...
I have an unfinished example that I made with wizard4 with burningsvideo and irrlicht 1.7.3 a few days ago for testing reasons and so on.

However, exporting directly in .b3d with its 8 uvmaps and importing it into irrlicht would make the task easier... too much. I'll see your code later, for now maybe I'll settle for having things in ram and passing them in vram between frames, if the image resolution is small it may not be so expensive to transfer it from cpu to gpu (for d3d9 or opengl), besides I usually render in low resolutions so... that, thanks again for the information.

(I want to upload the example, but complete with files and everything, I can upload the gif, but I don't know if wizard4 is willing to share the rest. By the way, I use 16 uvmaps, using d3d9 and opengl is still fast, I will upload the gif, but I will add the transition textures, currently there are 16 uv map and 16 horizontal angle textures of a soldier rendered in blender internal):




However, my style is usually more to use a very low resolution render, type 128x128 and add a bilinear filter, this gives it a pixel art and smoothed style, I really like that style, so I will upload an example using said style instead of the one in this image.


In fact, looking at the image, using only 2 uvmaps, front and back is enough, instead of using animated models you could use static models, have 8 .obj for a 1 second animation, using irrlicht 1.9.0 you could present the shadow for each .obj slowly until the next update... yes, it is quite feasible, there is no smoothed animation, it is more as if time were slightly stopped...

How easy is it to change texture and uvmap if I use solid or reflection2layer? To simulate smooth transition you could use reflection2layer to adjust the brightness of a panoramic image very high, just to make it look like the reflections change a little. I was making a game with wizard4 but we couldn't agree, he wants to make a game with sprites, I want to make a game with 3d models and use d3d9... sorry, I've always had problems with opengl, I've seen that even on YouTube people comment that they have problems with modern games that use opengl, not because Opengl is bad, but because the video driver is sometimes not 100% capable of using it...

[CuteAlien]

Yeah, that was only GL, I haven't used D3D for a few years. Because Irrlicht only supports D3D9 which is very outdated and misses features which I can get working in GL.

And sorry, but I did not understand your explanation about angles and why this needs uv-maps to be changed (instead of just texture changes).
Note that if it's about moving reflections around on top of another textures you can also move textures without changing uv's by modifying the texture-matrix.

[Noiecity]

Yeah, that was only GL, I haven't used D3D for a few years. Because Irrlicht only supports D3D9 which is very outdated and misses features which I can get working in GL.

And sorry, but I did not understand your explanation about angles and why this needs uv-maps to be changed (instead of just texture changes).
Note that if it's about moving reflections around on top of another textures you can also move textures without changing uv's by modifying the texture-matrix.

The bottom part is the uvmap, the uvmap adapts to the camera projection, blender internal uses z-buffer, cycles uses ray tracing for the projection, I understand so it is something more similar to w-buffer.
So, if the near, far and fov of the render and the uvmap projected at an angle are the same, the irrlicht will look practically the same (in fact in this example I don't even do this synchronization of fov and so on, only of angle):


The render:


The 3d model in irrlicht:



Logically it does not look exactly the same due to the background, if the background were black it would be practically the same lmao.

The problem with this method is that it only looks realistic near that same angle... it's difficult to explain but you need either a shader to make a smooth transition between one texture and the other, or the artistic style of the game is without said transition

[CuteAlien]

But why use a new projection for each angle? You only need to render new textures? I'm probably still missing something :-(
Note - you can always swap whole object as well. Show the one with the correct uv projection.
And yes - precalculated lightmaps are trouble if you rotate stuff. Thought you can rotate the texture in the opposite direction if you want keep the lightmaps lighting up the same place if you rotate an object. With texture-matrices.

[Noiecity]

But why use a new projection for each angle? You only need to render new textures? I'm probably still missing something
Note - you can always swap whole object as well. Show the one with the correct uv projection.
And yes - precalculated lightmaps are trouble if you rotate stuff. Thought you can rotate the texture in the opposite direction if you want keep the lightmaps lighting up the same place if you rotate an object. With texture-matrices.

Yes, using a new texture instead of changing the uvmap solves the problem, although to obtain the same quality you need it to be of a higher resolution in some cases, in some it is the same.

I will also use what you say, just change the texture, besides it is easier to transition textures with a single uvmap, in most cases you get the same result lmao.

Although for this we would not use angle projection in the uvmap, but rather a standard uvmap well propagated in uv space. Apart from the cases where the same texture in a uvmap, for example in a 1024x1024 texture, offers lower quality, it is only when it has interior floors, like a house or a boat, etc., then from an isometric view, for example, the uv projection would win since for 1024x1024 it would make much better use of the uvmap space(Or just separate the geometry into different materials instead of using a camera angle projection in the uvmap), but in most cases it would be the same, the only way this would not be true is that you use opencl or similar and directly ignore the background values, similar to the zero extended of x64 processors, but that would already be very specific outside of irrlicht.

I have had many computers in my hands, in all of them I tried irrlicht, and in opengl I always had problems, for example in computers the bilinear filter was different, almost not noticeable, in others it was very strong, maybe it was the driver configuration or something like that, and in almost all of them opengl offered worse performance, I don't remember a case where opengl worked better, and as I say, not because of opengl, it is because of the video drivers

[CuteAlien]

I'm pretty sure we're still talking past each other. If you want only 1 texture but move it over the model use a texture matrix (texture matrices have translate and rotate functions to make this easy). I thought maybe you need several because with more complicated models moving the texture makes no sense. But for those you also won't be able to use a single lightmap anyway and still have different rotations of same model. So in that case you'll end up with different textures anyway.

You really only need uv changes if the uv's change in a non-linear way (not simply move, rotate, scale, but completly different uv layout).

[Noiecity]

I'm pretty sure we're still talking past each other. If you want only 1 texture but move it over the model use a texture matrix (texture matrices have translate and rotate functions to make this easy). I thought maybe you need several because with more complicated models moving the texture makes no sense. But for those you also won't be able to use a single lightmap anyway and still have different rotations of same model. So in that case you'll end up with different textures anyway.

You really only need uv changes if the uv's change in a non-linear way (not simply move, rotate, scale, but completly different uv layout).

Using reflection2layer perhaps a similar result can be achieved, in my mind I imagine a skybox or any cube that contains a panoramic image in it. Basically I think I'm trying to do what you tell me, but in a different way lmao. I can simulate reflections when rendering in low resolution using RTT, for example I could go to Blender and use the camera in panoramic style to obtain the panoramic image, I think there are ways to convert said image into a usable skybox by irrlicht. Then I simulate what a mirror does, the light bounces from an opposite point until it reaches my eye, so that the color I see of the object is not that of the object itself, but the color that it failed to absorb the light, a mirror could make a part of your face shine if the light goes in that direction, changing the color of your face to a lighter color... ah I'm getting complicated, I simply render the cube simulating having a camera in the position of the object, the camera always looking at me, so that When the camera rotates towards my direction, the value of the cube where I have the skybox will be updated... ah, I keep getting complicated, most of the realism is in reflecting the light of a real environment on the object, reflection2layer achieves it coherently if the angle of reflection matches the light that bounces off the surface towards your direction, basically you render the cube where you have the skybox all the time, but not the entire scene, then you pass said texture to the 3D model, the skybox could be the interior of A house for example, houses having structures with little light reflection or a roughness that is too high, almost does not bounce light, but it does, so as the reflection2layer multiplies on top of the first texture, you simply increase the brightness of the skybox texture a lot, the more brightness is equivalent to less reflection, then you will get a realistic surface when you move... ah but I am getting too complicated.

I am in front of a wall, the camera that will create the reflection2layer texture is looking at me at a relative distance, in reality this camera is not on the wall, it is in another place inside a cube that has a skybox, if I move to the right, the camera rotates towards the direction in which I move, then I will notice that the light on the surface of the object varies according to my position, and the colors match the environment, so it is more noticeable that the light bounces and that is what I see... even if it is a lie.

Edit: I wrote too much, you may just need to read the end to explain my point... moving using the matrix projection is a good idea in this case too, I thought about it even though I didn't know the name, but I ran into the problem of the edges, since a skybox is like a "seamless image", that is, as if it had neither beginning nor end... ah but I get complicated, a wall will at most have 90 degrees, what I say is only useful for an object that you can observe from many angles such as a metal helmet or something like that.


edit2: Yes, I'm definitely getting complicated, it's better to just put a camera on the wall facing you and get the RTT directly from that...
viewtopic.php?p=307799#p307799
ah, but it was because of the issue of how much reflection do you want from that... then you would have to post-process the RTT so that the brightness increases, so it would look more like a very rough object

[CuteAlien]

Trust me I know that realistic environment light is tricky. I spend last 4 months full-time on that and I'm still failing. At least once you go beyond a simple metal helmet and an environment map (yeah, I know that demo as well ^_^)

[Noiecity]

Trust me I know that realistic environment light is tricky. I spend last 4 months full-time on that and I'm still failing. At least once you go beyond a simple metal helmet and an environment map (yeah, I know that demo as well ^_^)

I see that my eye does something that I also want to replicate, I will exemplify it according to how I think it could work in irrlicht but I still can't achieve it:

My eye projects a ray trace towards the object that is right in the center in the direction of the center of the eye, that entire area is focused, but everything far from it is blurred, and very close too, it is not like a circular area or something like that, it is more like the brain distinguishes the distance at which the light is bouncing directly to my eye, and blurs all the area that does not come from that same distance relative to the bounce...

In irrlicht, there are examples where a ray is drawn in the direction of an object, for example a triangular face, the closest thing to this is irrlicht's mipmaps, but mipmaps is far from similar, but it is not bad, it is more like it renders 3 times.

First render: near:10, far:100
Second render: near 80, far: 200.
Third render: near: 180, far: 300.

To the first and third render I can add a bilinear filter, the second render will be in focus, then one from the last to the first... these would already be realistic mipmaps, the near and far of the second render depends on where the ray trace collides with the triangular face... then you would have a rectangular area focused near that collided ray, and everything else out of focus...

Not only that, the center of the eye is always in focus, while around it it is always out of focus, I could add a post processed that once joins the 3 renders, blurs circularly like a soft gradient... and all this is similar to the stars in the sky, as if the focus were the light generated from the sun of this solar system, and the blur were the other stars in the distance... but they are all stars after all.

I saw this in some magazine but I don't know where... while I was looking for how to apply this kind of realistic mipmaps I found someone who wrote a shader that did that, rendered 3 times and joined...

[Noiecity]

Okay, I was thinking about how to make full use of the space on a 3D sphere. I realized that having multiple UV maps here would have been helpful, since half of the sphere takes up almost the entire UV map. But after giving it some thought... of course, I said to myself, I’ll just use two UV maps—one for the front and one for the back. Irrlicht allows you to store two UV maps... but it requires shaders to switch between UV maps in a material...
So I figured it out—there’s a better solution that also offers better performance: you have to keep using just one UV map. I remembered that UV maps can overlap, meaning two different triangular faces can occupy the same space in the UV map. This is generally considered an error, but it isn’t in some contexts (like with mirrored geometry, which isn’t the case here). This solves the problem: I make them overlap, separate by materials instead of UV maps, and that’s it—each material has the same UV map and uses the space efficiently. This is actually more efficient than constantly switching UV maps. Now I can achieve the same quality with the same texture resolution for the sphere. Thanks, Mr. CuteAlien. However, I have a question: you mentioned global textures that weren’t well supported and that were per material, but are there 8 textures per material, or 8 textures total per 3D model? For example, do I assign 8 textures to material 1, another 8 textures to material 2, and so on, or are there 8 textures total per 3D model? If that were the case, the only solution would be to split the geometry into parts. But that wouldn't be feasible because I'll be using volume shadows in an optimized way.
Oh wait, Irrlicht lets you have a secondary model to cast the shadow. That’s actually really useful now that I think about it. I was worried about using models with too much geometry and that the shadow volume wouldn’t be able to handle it… but I can have the shadow volume with lower-poly geometry… though, how does that work when it comes to casting a shadow on itself? Well, I don’t think it would look much different if the surface is fairly close enough.

[CuteAlien]

You can have 8 textures per material. You have 1 material per meshbuffer.
You can have as as many meshbuffer in a mesh (model) as you want. Basically a main point of a meshbuffer is to split the parts in a model which have different materials.

UV's are in the mesh (S3DVertex) - not in the material. So you can't have UV's per material.

[Noiecity]

You can have 8 textures per material. You have 1 material per meshbuffer.
You can have as as many meshbuffer in a mesh (model) as you want. Basically a main point of a meshbuffer is to split the parts in a model which have different materials.

UV's are in the mesh (S3DVertex) - not in the material. So you can't have UV's per material.

Thank you so much, mr cuteAlien. I hope you are greatly blessed in this life for your kindness in answering these questions
(I’d ask ChatGPT, but there are some things I feel more confident about hearing from a developer who’s actually seen how the source code works)

[CuteAlien]

Thanks, maybe the blessings arrive in the next life ;-) And no worries, I'm always happy when I see other people still using the engine as well.