HODOR Skybox Adventures

I’m trying to convert a textured skybox through blender into HODOR, and so far it’s not working out HODOR says it’s creating a file, then it crashes. As far as I can tell I’ve mimiced the example files as closely as I can, and I combed the inlcuded coumentation and found nothing. All my files, sources and exports, can be checked here. The HWRemasteredToolkit addon was used in hopes that it’d help the export.

Please note that the textures aren’t exactly final, but it seems that once the pipeline issues are sorted out we should be able to swap those out for other ones quite easily. Also the lighting values are known to be insane.

So I battered my head against that for hours before posting about it, then less than a minute after posting noticed that the plugin adds a new export option instead of modifying the existing one, and that makes a dae that doesn’t crash HODOR. So, nevermind then.

Well, I got hodor working, but game crashes without useful error messages when I try to pop it into a loadable background. Link above updated with current source and output files.

Ed: Opened the example DAEs in text and noticed that there’s some properties in the light nodes that I couldn’t see in blender. Will have to try again with those added in and see if that helps.

You should Skype with me sometime, if you have time. Otherwise, PM me some of your DAE or HOD files - and I can look into what troubles you’re having…

1 Like

Sent you a PM with contact info. The most recent Hod/dae files are available at https://dl.dropboxusercontent.com/u/896078/Farorbit_VayGC2.7z, but I haven’t gotten back to trying it after noticing those missing tags, and likely won’t for at least a couple hours.

I haven’t gotten around to updating the Blender tools to handle the Background light sources yet (having two different colour parameters makes it more complicated, since custom properties don’t support color selectors, and I have to add some more conditionals in the export script for building the names for background lights). It’s pretty much just ships now, unless you want to manually edit the xml after creating a DAE to pop in all the light parameters. Unless a PARAMS node works for LITE nodes, but BitVenom will have to tell you the structure for that.

I’ve tried hand-editing the xml to put the missing tags in, which didn’t help. This morning I noticed that the background I’m replacing has a key_flare joint that I haven’t replicated. It seems possible that the other files of the background are trying to put a lens flare on that joint, and it missing is crashing… that’s my next troubleshooting step.

I’m taking a look at your files. Have you manually triangulated all your meshes before exporting?

Visual Studio crashes when trying to open the for_hod.dae, which tends to happen if the mesh isn’t actually triangulated.

Also, what’s the deal with using the weird box instead of the BackgroundSphere.obj in the Background Source folder?

I hadn’t triangulated when I exported, no. If that’s something that HODOR needs I wasn’t aware of it. As for the shape, I’m trying to import a skybox texture that I exported from SpaceEngine. @matththegeek has already done a similar background, which works fairly well(Ed: I’d use his files, but his skybox mesh is tilted which is a bit inconvenient). Our old backgrounds are sphere textures, but that’s not an option for space engine exports.

Triangulation isn’t about HODOR, it’s about the DAE format in general. If the mesh isn’t actually triangulated, but the dae says it is (which it does, because that’s how I made the Blender exporter do it) then the faces get built wrong and then that cascades to messing up the UVs and the material assignments and everything else. HODOR won’t throw any problems because HODOR isn’t actually trying to render it, but as soon as anything tries to render that geometry it basically goes “wtf is going on here?” and crashes.

Aha, I didn’t know the exporter assumed triangulation. I’ll add that to my troubleshooting to-do, thanks for the tip.

Tried all those steps, still crashing the game :frowning: The dropbox archive is updated with my latest attempts.

I’ll look into it (hopefully) in a debugger before Morning… :smile:

I appreciate it! I’ve updated the dropbox archive again, this time including all the background files that I’m using together. Except the main _light.hod file they’re taken from @matththegeek’s skybox background, which I’ve tested by itself and appears to work.

I’m really confused… the zip you sent has a ‘gamefiles’ folder that is working for me. The background is busted and ugly, the lighting is blown out to hell, but it does work, no crashes, etc. If the _light.hod isn’t yours, then what exactly are you trying to do? The _light.hod file is where most of the magic happens now, and that could be your issue (again, I am not crashing). We can talk if you have time, just PM me with a window.

The _light.hod is 500MB!!! That’s certainly one thing you shouldn’t do… Yes that is with uncompressed textures - but even then you’re talking about 125+MB for a pretty basic skybox. 99% of the time the way you’re doing that is just wasted space…

I would highly recommend taking your 6-sided 4k x 4k box and baking it onto one of our example spheres (very, very easy to do in Max, if you don’t have Max, maybe ask a community member?) - you’ll get a very similar background for 1/4 the final size - one that won’t nuke many of the machines that can run this game.

The _light.hod is the one file that was mine, the rest are taken from the other background. I’m rather certain it was crashing me still on the last iteration. I’ll check myself as soon as I can.

In my experience sky-spheres have issues with detail near the poles that boxes avoid? Spheres definitely see easier to hand-draw, but since that’s not an issue in this case I’m a bit confused by the idea that spheres would be more efficient. It seems lije the relationship between texture memory and visible detail level would be similar overall? The 4k^2 texture size is unlikely to stay, it’s just the size of the export I grabbed to test with. Once I have a working hodor pipeline there’ll be a lot of iteration to find the right texture size, source and destination lighting setups, and so on.

Maybe the huge textures are causing me issues. I guess that’s something I’ll have to check today.

Even as 3D this game is still ‘mostly’ on a flat planar orientation. Less detail at the poles in order to focus detail where the user most often looks is a pretty sane decision. When you use a Sky-cube the ‘corners’ have a different texel density than the face centers on-screen - though that’s often a minor issue.

In addition, something you can do (that we didn’t) is slice off the poles and texture them with even more detail - so that overall the quality is fairly uniform.

One thing to note - many of our levels have very ‘basic’ skyboxes - with extra elements (not just 3d planets!) floating between them and the gameplay area - those even have VERY subtle parallax. This allows stuff like the planets/moon, even the galaxy in your map to be their own objects with unique textures - and not have to fit the shape of the background one way or the other - a win-win.

Okay, downscaling the textures made it stop crashing the game. I feel a bit silly for not doing that sooner, but I hadn’t actually realized the test textures I grabbed were 4k initially. There look to be some pretty big geometry errors though, I’m doing a version with non-black textures so the details will be more visible. Perspective issues on the corners that are rendering are also visible, which is… disappointing.

In an ideal world I’d definitely be taking advantage of that. SpaceEngine exported skyboxes aren’t an exact fit for what I want out of homeworld backgrounds, but they are very pretty and we don’t have access to a dedicated background artist. If I get this working, it’ll be a huge labor saver in our mod.

With colored panels for better edge visibility, this is how my testBG looks like ingame:

The faces seem out of position and two(ed: was three, looking at this thing is disorienting) aren’t rendering at all, though given the hints of purple they might be there somewhere even if it’s for some reason they’re not fully visible. I’ve had someone with max look over my dae and they can’t see anything like this issue in it. I’ve uploaded the relevant files to dropbox. https://dl.dropboxusercontent.com/u/896078/test_bg.7z

Is it possible something has changed betwen the public versions of the game/hodor and the one you’re using that would have fixed this problem?

Nope - not in the least - mi HODOR tu HODOR.

What is really odd is that with the .hod you most recently uploaded I’m not seeing any of this, at all. It’s broken, visibly - but not the wrong colors or having trouble with the depth-buffer, etc. The best way to tackle this may be to get some time to Skype with me. Though today is a bit rough, I’ve got meetings and other things. I can probably still find time if you let me know your availability…

PMed you about availability. Will keep troubeshooting some on my end, going to try the background without the rest of the mod files involved and see if that changes anything. I wouldn’t think it would, but if we’re getting different results it seems best to remove variables.