I love irrlicht, but I'm very stupid programming in it

[Noiecity]

I am a digital artist, but very poor in terms of irrlicht technical knowledge, I would like to build a project with someone, anything.

I can model, texture and animate anything imaginable within irrlicht's graphic capabilities (which are high), but I'm very bad at programming.

I had not programmed in c++ until I met irrlicht a few months ago, I loved it, everything complicated about directx9 sdk in easy mode and on a serving tray, but I am very stupid

I just want to see my art reflected in some irrlicht game u_u

aid

[CuteAlien]

Maybe also give Godot a shot. It's a bit easier to get into than Irrlicht maybe.

And I hope you have some IDE and don't just work with Nodepad++ and Makefiles? I mean - it's OK if you prefer that (some people do), but Visual Studio probably makes life a bit easier.

I'd also recommend switching to svn trunk version of Irrlicht. It's just better by now than the official 1.8.5 release.

Good luck either way :-)

[Noiecity]

Thanks

[Noiecity]

The examples inside the test folder are very good, it also has screenshots haha, I would like to know if there is any way to build an equirectangular panoramic camera in irrlicht, and obtain the render at an angle of 230 degrees

[CuteAlien]

Hm, I have some solution, but it's not really meant for realtime.

The first thing you need are rectangular renders in 6 directions, each with a FOV of 90°. Easiest done using render target textures. The 28.CubeMapping example in Irrlicht svn trunk has code which nearly does that. renderEnvironmentCubeMap renders in all 6 directions - except in your case you probably need to render into 6 individual rendertargettextures instead of putting it all in a single cubemaptexture as that code does.

I'm not sure what you mean with 230° render angle (the result is basically a sphere), but if you want to ensure a specific camera direction is set you can do that also in that step.

Then I got a function (mostly from the stackoverflow link mentioned in code) which calculates the equirectangular texture from those images. Just have to be sure they are all in the right direction and order (you may have to experiment). Minor note: The direction checks in that code might fail in Irrlicht 1.8 (that had over-optimized some divisions), in which case replace the extDir == 1 checks by unitDir == a checks (I'll have to rework and test that myself, but can't do that right now). You know it goes wrong when it jumps in the last else (so you can set a breakpoint or something).

edit: Seems that functions expects all 6 images copied into a single texture, so you'd have to either copy the rendertargettextures together first (easy, but slow) or rewrite it slightly so it works with 6 independent textures instead.

Code: Select all

// What you put in is an image with is 6 quadratic images (cubeImg) side-by-side in a fixed order (we use the same order as vray)
// The cubemap is created by rendering a camera from a fixed position to each side (with 1:1 width/height ratio and 90° FOV)
// The function calculates from that cubemap a texture which can be put on a sphere.
// 
// Think about putting a sphere in box.
// Calculate for each texture-coordinate the direction a line from the center needs to have to hit the sphere at those coordinates.
// We're using polar coordinates for that.
// Then expand that line until it hits the cube.
// Find out which side of the cube it hit and you can get a coordinate on the cubeImg from the point it hit.
// It's based on answer from Bartosz here: https://stackoverflow.com/questions/34250742/converting-a-cubemap-into-equirectangular-panorama
void convertVRayCubemapToEquirectangular(irr::video::IImage* equiRectImg, const irr::video::IImage* cubeImg)
{
	using namespace irr;

	if ( !cubeImg || !equiRectImg)
		return;

	core::dimension2du targetDim(equiRectImg->getDimension());

	float u, v; //Normalised texture coordinates, from 0 to 1, starting at lower left corner
	float phi, theta; //Polar coordinates

	u32 cubeFaceWidth = cubeImg->getDimension().Width / 6;
	u32 cubeFaceHeight = cubeImg->getDimension().Height;

	for (u32 j = 0; j < targetDim.Height; j++)
	{
		//Rows start from the bottom
		v = 1.f - (((float)j+0.5f) / targetDim.Height);	// the +0.5f to get the pixel center
		theta = v * core::PI;
		float sinTheta = sin(theta);
		float cosTheta = cos(theta);

		for (u32 i = 0; i < targetDim.Width; i++)
		{
			//Columns start from the left
			u = (((float)i+0.5f) / targetDim.Width);
			phi = u * 2 * core::PI;

			core::vector3df unitDir(sin(phi) * sinTheta * -1.f, cosTheta, cos(phi) * sinTheta * -1.f);

			// Unit dir extended until it hits one of the cube faces
			float a = core::f32_max3( core::abs_(unitDir.X), core::abs_(unitDir.Y), core::abs_(unitDir.Z));
			core::vector3df extDir(unitDir/a);

			f32 cubeU, cubeV;
			u32 xTile;	// to find the correct tile in the cubeImage

			if (extDir.X == 1)
			{
				//Right
				xTile = 0;
				cubeU = ((extDir.Z + 1.f) / 2.f) - 1.f;
				cubeV = ((extDir.Y + 1.f) / 2.f);
			}
			else if (extDir.X == -1)
			{
				//Left
				xTile = 1;
				cubeU = ((extDir.Z + 1.f) / 2.f);
				cubeV = ((extDir.Y + 1.f) / 2.f);
			}
			else if (extDir.Y == 1)
			{
				//Up
				xTile = 3;
				cubeU = (extDir.X + 1.f) / 2.f;
				cubeV = ((extDir.Z + 1.f) / 2.f) - 1.f;
			}
			else if (extDir.Y == -1)
			{
				//Down
				xTile = 2;
				cubeU = (extDir.X + 1.f) / 2.f;
				cubeV = (extDir.Z + 1.f) / 2.f;
			}
			else if (extDir.Z == 1)
			{
				//Front
				xTile = 4;
				cubeU = (extDir.X + 1.f) / 2.f;
				cubeV = (extDir.Y + 1.f) / 2.f;
			}
			else if (extDir.Z == -1)
			{
				//Back
				xTile = 5;
				cubeU = ((extDir.X + 1.f) / 2.f) - 1.f;
				cubeV = (extDir.Y + 1.f) / 2.f;
			}
			else // even with floats x/x should always be 1 or -1, so shouldn't get here
			{
				cubeU = 0.f;
				cubeV = 0.f;
				xTile = 0;
			}
			cubeU = core::abs_(cubeU);
			cubeV = core::abs_(cubeV);
			f32 xPixelCenter = cubeU * (cubeFaceWidth-1) + 0.5f;
			f32 yPixelCenter = cubeV * (cubeFaceHeight-1) + 0.5f;
			irr::video::SColor c(cubeImg->getPixel((u32)xPixelCenter+xTile*cubeFaceWidth, (u32)yPixelCenter));

#if 1		// bilinear filter (I think, not 100% certain if bilinear works exactly like this, but filters pixel with neighbors in 2 directions)
			f32 d = 1.f;
			irr::video::SColor cx;
			f32 xpc2 = -(f32)cubeFaceWidth;
			f32 xm = fmodf(xPixelCenter, 1.f);
			if ( xm < 0.5f )
			{
				xpc2 = cubeU * (cubeFaceWidth-1) - 0.5f;
				d = xm*2.f;
			}
			else if ( xm > 0.5f )
			{
				xpc2 = cubeU * (cubeFaceWidth-1) + 1.5f;
				d = (1.f-xm)*2.f;
			}
			if ( xpc2 >= 0.f && xpc2 < cubeFaceWidth )
			{
				irr::video::SColor c2(cubeImg->getPixel((u32)xpc2+xTile*cubeFaceWidth, (u32)yPixelCenter));
				cx = c.getInterpolated(c2, d);
			}
			// TODO: wrapping options (complicated and probably hard to notice, let's ignore...)
			else
			{
				cx = c;
			}

			irr::video::SColor cy;
			f32 ym = fmodf(yPixelCenter, 1.f);
			f32 ypc2 = -(f32)cubeFaceHeight;
			if ( ym < 0.5f )
			{
				ypc2 = cubeV * (cubeFaceHeight-1) - 0.5f;
				d = ym*2.f;
			}
			else if ( ym > 0.5f )
			{
				ypc2 = cubeV * (cubeFaceHeight-1) + 1.5f;
				d = (1.f-ym)*2.f;
			}
			if ( ypc2 >= 0.f && ypc2 < cubeFaceHeight )
			{
				irr::video::SColor c2(cubeImg->getPixel((u32)xPixelCenter+xTile*cubeFaceWidth, (u32)ypc2));
				cy = c.getInterpolated(c2, d);
			}
			// TODO: wrapping options (complicated and probably hard to notice, let's ignore...)
			else
			{
				cy = c;
			}

			c = cx.getInterpolated(cy, 0.5f);
#endif
			equiRectImg->setPixel(i, j, c);

#if 0 && defined(_DEBUG)	// TEST: show the extDir results (in range 0-1)
			irr::video::SColorf dummyTestf((extDir.X+1.f)/2.f, (extDir.Y+1.f)/2.f, (extDir.Z+1.f)/2.f, 1.f);
			irr::video::SColor dummyTest  = dummyTestf.toSColor();
			equiRectImg->setPixel(i, j, dummyTest);
#endif
		}
	}
}

But as mentioned - not realtime. That would need at least the last calculation to be done on a shader (I might have that one as well somewhere if I hunt around my codes a while). And you still have to render the scene 6 times (I don't think that can ever be avoided). Maybe I can recommend better options if you can tell me what you are trying to accomplish.

[Noiecity]

What you say is excellent, although, if I was thinking about it in real time, I had also thought about something like what you mention, I just had no idea how to achieve it, I thank you very much, the 230 degree angle is an approximation of the vision that we human beings have according to what I understand, we see in front and near around our ears with our eyes, we see the center focused and sharp and near the edges blurry, I wanted to achieve a realistic perspective, although I had also considered that perhaps the calculations in our eyes are more like an orthographic camera than a perspective camera, as if it took thousands of renders in different directions and combined them to shape what we see similar to a perspective camera, or that impression gives me .

I thought that perhaps the correct way to achieve this effect with an orthographic camera is for each pixel to render a direction, taking the center of a circumference as a reference. So if we have 800 width and 600 height, we would have to divide 360 degrees by 800, that would give us that for each pixel 0.45 degrees in width are rendered, then repeat this changing the rotation of the circumference, that is, repeat this every (360/600), that is, every 0.6 degrees of rotation, so we could obtain the perfect perspective of our eyes, then we would have to obtain an approximate of what our eyes see and subtract them to obtain a more exact result, I estimate that about 230 degrees, now, then we would have to add blurred pixels to the degrees that are not close to the center of 800/600, like a bilinear filter, but I have no idea how to achieve it hahahahaha, but I like to share the analysis of this assumption, although trying to move the CameraSceneNode made me understand this logic.

Once again, thank you, I hope to be able to show the results soon and make them known in the forum

[CuteAlien]

Interesting idea and also quite a rabbit hole. Like at the sides you only notice monochrome differences. Also sharpness varies a lot. And certainly parts are not optical at all but your neurons doing work (like combining 2 images into one with depth and switching it upside-down from the perceived one).
You probably should think about faking it when it's about a game. The values I found on a quick search for horizontal FOV were 200-220° max, but guess
same problem. Vertical 130-135° (minor side-note - field of view in Irrlicht is vertical for some reason).

This all sounds like it should be done with shader coding later (but not bad to figure it out on CPU first). Thought you still have to start with the real renders in each direction. Reducing amount of renders can probably be done as your view range should be somewhere around the size of a motorcycle helmet visor. Putting a cube around helmet I don't think you'll ever see the back-side, that's one side gone. And as you don't need the usual flat frontal view render you may instead rotate the cube 45° down. And then maybe you can forget about rendering 2 back sides already. Not sure if you can get rid of 3 sides, looking exactly at a corner of the cube maybe?

But I'd probably start first with adapting the polar coordinates in convertVRayCubemapToEquirectangular. Getting a kind of visor is nearly automatic if you reduce the range from a full circle to less than that. And vertical/horizontal is already split. Probably more fun for you to figure out those parts yourself, but don't worry about asking again.

Hope it all made sense... I'm a bit woozy right now from a pretty bad flu 🤮

[Noiecity]

thanks again

[Noiecity]

Lol I just confirmed that our view is really more similar to an orthographic camera that takes each pixel as a different angle from the same center of circumference

(Blender)


^ 180/1024 (Orthographic)



^ Ortho default


^ Perspective default

[CuteAlien]

That first one should be a perspective render, not orthographic (backgorund box gets smaller).

[Noiecity]

It is orthographic, our real world is also orthographic, in fact in mechanics this view is used for parametric measurements, but what our eyes see, the light that enters them and is interpreted by our optical nerves, makes us see in perspective, so simulate the same thing, what I just did is known as non-euclidean geometry.

The renders were all from the same location, the difference is that the 180 degree render did not trace in just one direction, but in each direction, that is, as if you had had a camera for each pixel pointing at each degree, and It was using the blender orthographic camera, and that's how you got that result (it wasn't easy), it was better than the result that the equirectangular camera gave me, which surprised me, equirectangular also deforms the image

[Noiecity]

When I see the seventh example of irrlicht again, apart from the fact that it makes me want to build games, an idea occurs to me to create another type of camera, the colliding path may be able to give me the color of the RGB texture of that one. pixel, if that is the case, I could try more paths and form an image of everything I capture in the same spherical circumference, it would give me something like a skybox, if possible, then a real perspective can be simulated, although I don't know what performance would have

[Noiecity]

I give up, I better make a game with what irrlicht currently offers me haha

[CuteAlien]

Sorry, I still don't understand what you do in the 180/1024 (Orthographic). The cube background simply looks like a perspective projection and not a orthographic projection. Unless that's no cube. Or maybe just send a screenshot of the Blender camera parameters :-)

You talk about tracing - but if you mean light-tracing, that is independent of the projection. That's about the light-calculation. And yes raytracing looks better than realtime calculations. Especially those which don't even include any enviornment light (like Irrlicht). But that is not a camera thing. Irrlicht's light calculations are by default quite out-dated (like 20 years). Still possible to get some cool stuff with it, but for better results you'll have to write shaders.

[Noiecity]

How ironic, yesterday I was working with the shaders, but the drop in performance did not convince me. Blender is that, literally take the camera in orthographic view, take a render until you achieve 360 in 360 degrees, take 180 degrees in X for every 180 degrees in Y, and divide each render of the 180 degrees into the pixels of the image .

You can check this yourself, since I discovered an easier way, if you take a sphere and add low roughness and metallic at 100, and give it a render in orthographic view, the reflection of the sphere will also appear in perspective view, of course , in this example the radius is much larger than a single pixel, but it works, all this is with blender 2.79b by default, without adding anything, the renders can be automated in python, and chatgpt can help you with that, too you can ask chatgpt to make you a mathematically perfect sphere and it will do it for you in python