a space game I've been working on for a while

[SomeGuyWithAComputer]

Here is a video of a space game I've been working on for a while. It uses Irrlicht, reactphysics3d and OpenAL. It also has built-in lua which will be used for possible mods or quest scripting in the future. For now, just the cockpit monitors and some of consumable items (not shown in screenshots or video) run on lua.

Next I'm planning on making it so that the planet surfaces can be landed on and walked around on. The first problem I'm aware of is that the ITerrainSceneNode object HAS to have its heightmap data loaded from a file on the drive which isn't suitable for all this procedural generation stuff. If I can't find some way of getting heighmap data into an ITerrainSceneNode without loading from a file, I'll come up with my own mesh terrain heightmap plane node or something. Reactphysics3d will be used for handling the terrain collisions either way. I'm sure I'll end up finding some way to get planet terrain working considering everything else I've already done.

https://youtu.be/4VSW6YB8KMc

screenshots:










I welcome any thoughts or suggestions.

[CuteAlien]

Nice to see. File reading can be from memory with IFilesystem::createMemoryReadFile, maybe that helps.
And after watching your video I noticed our website link to the .wav file with "Irrlicht" pronunciation is no longer working. I'll look into that ;-)

[SomeGuyWithAComputer]

Thanks. That function worked like a charm.

This probably isn't worth its own thread (yet), but one issue I'm running into is that I need to basically get a list of all the indicies and all the vertices from the terrain mesh in order to generate a reactphysics3d collider. Both ITerrainSceneNode->getIndexCount() and ITerrainSceneNode->getMesh()->getMeshBuffer(0)->getIndexCount() seem to return zero when I run it. Maybe I have to generate a TerrainMesh copy of this in order to get it to generate valid index data. Maybe there's another way to generate/get this data and I'm just doing it wrong.

Another curiosity of the ITerrainSceneNode is that ITerrainSceneNode->getMesh()->getMeshgBuffer(0)->getIndexType() returns 1 which means 32 bit indicies. Not sure if all ITerrainSceneNodes always get generated with 32 bit indices or not but I'm using a 1024x1024 heightmap texture for this so it's rather large. getMesh()->getMeshBuffer(0)->getIndices() returns a u16* so I assume I'm supposed to do this:

Code: Select all

u32 *indices = (u32*)n->getMesh()->getMeshBuffer(0)->getIndices();

There is also a function called getIndiciesForPatch() that I haven't done much with yet. It's possible this is how to do it. I'm not quite sure what the patchX and patchZ stuff means yet but perhaps some trial and error will be enough to figure it out.

[CuteAlien]

Hm, maybe take a look at the source. I would have to do that as well for this one, as it's one of the nodes I'm least familiar with. Haven't used it yet in any of my own projects. But I remember last time I checked there were a few things in which that node worked a bit special. It looked a bit to me like someone ported some code to work with Irrlicht, but didn't look too much into how Irrlicht worked otherwise when writing this one (but I'm completely guessing, could be there were other reasons).

[SomeGuyWithAComputer]

It turned out I was barking up the wrong tree on this one. I was trying to get the verticies of the terrain and make a collider based on that. I then realized that an ITerrainSceneNode created with a 1024x1024 heightmap contains 1048576 verticies which is probably way too many. I then used reactphysics3d's heightmap collider to make a collider based on the procedurally generated heightmap.

This mostly worked. After some fenangling I got the 0 height value and the 255 height value to match on both the irrlicht terrain and the reactphysics3d collider. I seem to need to multiply the ITerrainSceneNode scale on the x and z axis by 1.0148809 to make it be the exact same size as the reactphysics3d heightmap collider that is created with supposedly the same size.

The most notable weird thing is that certain height values between 0 and 255 still don't match and are off by an altitude of up to half a meter. It doesn't seem to be related to the scaling since the highest and lowest heights always match. I think it has something to do with either irrlicht terrain smoothing or integer rounding in the code I made for it. There are a lot of things I could try to try and fix this problem so if I find something postworthy while doing this I'll post about it

The ITerrainScene node is pretty great and I think this is going to work, I'm glad I didn't have to make one myself. The only 2 "issues" are that the terrain doesn't follow parent nodes if you try to put it in a parent node and also it lags a lot if I try to rotate or move the terrain node. For me, this just means the outside environment (stars, planets, etc) will have to rotate around the terrain to get a day/night cycle.

[CuteAlien]

Yeah, positioning & rotation was one of the things - it doesn't follow the usual ISceneNode scheme. And not sure if there was any reason or simply because the code was ported from somewhere without checking how Irrlicht usually works.

[chronologicaldot]

Nice to see another space sim!
Someone else on the forum was doing a space sim too, but I forget their username. "gravity"?

[Granyte]

I"m working on a space sim too still lurks around every once in a while.

Nice to see a fellow space explore. If you need any help with solar system scale rendering and simulation hit me up I'd be happy to help if you need.