Making Subsystems

Is there anything new we should be aware of, or gotchas, cool tricks with subsystems we should be aware of with the new updates, HODOR, planned down the line, etc?
I am Planning on going sybsystem heavy and thought to ask since I did not want to get part way and find things changed.

I am assuming weapon joints, nav lights, hit meshes, etc are all the same as a ship examples? are there any points which can’t be used?

Is there anything stopping you from having a base frame and "building an entire ship with subsystems, Meshes, extra abilities and all? (I have not run into anything yet but again best to ask.)

The HOD format is going to get a pretty big rebuild. Most ‘asset’ data will end up in some dense bundles (one for Textures, one for Geo) - the majority of the remaining data will end up in external files that have a quick-loading binary version, but also an ‘easy tuning’ text version. Let’s call those ‘structure’ files. They tell the engine to make a tree of data, then hang various visual/simulation data on it (meshes, collision, etc).

  • The external data won’t be a single file - as I’ve covered before in regards to ‘ship patching’ - mods can add files (instead of over-riding an existing file) - to change joints/markers, or just add new ones. Ditto for making reference to new mesh or related bundles.
  • The asset bundles themselves will be referenced by the ‘structure’ files (aka put Root bundle on Root joint). They will also be dense and highly compressed/optimized. Editing them in any capacity will be virtually impossible. HODOR will create them for you from well-formed DAE files.

I don’t know that any of this will add features (maybe, but doubtful) - or break features (um, no). Generally it should be possible to add markers/hard-points, bind meshes to them, add nav-lights, etc - without having to hack at all - even on top of existing ships or mod ships. I’ll also probably extend HODOR to load a ship (with all of these extended files) like the engine would and spit out a ‘proxy’ DAE so that other tools can be used to see how things line up, etc.

2 Likes

Thanks, I just read that in another area, sounds great.

One more thing, I am used to MAX and getting used to Modo. But not used to exporting in the .dae format and am unsure of the limitation of it or of hodor with various feature sets in MAX. Ie supports fully triangular mesh or is polygonal ok? and (does it process it anyway or should I do that to make sure everything works well- ie can but not recommended) I assume no patch or spline based models :P. And what about the modification stack’s? does it all behave? I know FBX can get finicky how it handles things and what is ignored.
Also on textures, You said that Hodor just uses the texture references (right) in the dae and processes them as needed. I assume that also means it is not going to combine textures. ie I have a model with mutable layers of textures just for the diffuse map (repeating hull texture, grime, tinting etc all with there own UV) I assume? a single UV for the entire ship with a single defuse map (all the others baked) has to be made? as this is not happening in HODAR? Just want to make sure I do not go though the possess without need as it is a bit of a process (but possibly required one) to combine my ships into one object unwrap them and bake the textures.
Thanks

I think 90% of what you’re asking (which is pretty dense, damn man! :slight_smile: ) - can be answered by looking at our examples.

The DAE Export will usually collapse the stack and leave just polygons. It shouldn’t allow complex surfaces. Texturing is complicated because the system is actually much more flexible than even we’re using it. Some of our stuff has vertex colors, some has multi-UV layers (up to 4), etc. It really depends on you. You don’t have to bake down everything to a single texture - not at all. We don’t ‘auto bake’ to a single texture because different surfaces may have different shaders and may want that data a certain way. Some shaders may want to UV animate with a known UV layout - baking would nuke that.

Generally you want a single UV for your surfaces - for the aggregate ‘Diffuse’ map. Badges are an example of a 2nd UV set being needed for a texture that the engine defines. You could create a surface/shader in the engine that wanted 4 UV sets. And then in Max/Modo/Blender you’d have to author those. It’s a bit hard to talk definitively about it because of all the flexibility built into the engine. I really tried to imagine 10 years from now people still pushing this and coming up with crazy ■■■■ - and allow for it.