Questions About Bridges

[Elijah]

Hello all,

Had some questions and I wasn't seeing what I was looking for so here we are.

1: Has anyone made a step by step guide on how to go from a model in Max/Blinder to a working bridge in game?

2: What applications and tools are used from going from a model to in game?

3: Do people really use Max 3.1 to export the NIF files?

4: What issues exist with more modern exporters that prevent bridges from working properly?

5: What is special about bridge models that is different from ship models?

[Lurok91]

I used to have a stickied thread here that answered many if not all of those questions (especially 1 - 3).   I'm not sure where it went to or if someone kept a copy.  Possibly Morgan/Nero might have saved somewhere?

duh - it's here....

http://bridgecommander.wikidot.com/bridge-modding-101

[Elijah]

I used to have a stickied thread here that answered many if not all of those questions (especially 1 - 3).   I'm not sure where it went to or if someone kept a copy.  Possibly Morgan/Nero might have saved somewhere?

duh - it's here....

http://bridgecommander.wikidot.com/bridge-modding-101

Neat, I'd actually gotten linked to that on discord the day after I posted this. I'm trying to look into the NIF format and such to create some new import/export tools for 3ds Max, do you have any ideas about 4 and 5?

[JimmyB76]

I used to have a stickied thread here that answered many if not all of those questions (especially 1 - 3).

your thread Bridge Modding 101 is in Tutorials subforum BC Modding...
Perhaps it would be better in this forum instead... I'll go ahead and move it...

[Lurok91]

 

[Lurok91]

5: What is special about bridge models that is different from ship models?

They use same principles but there's more complexity to bridges as you're working with many more different elements.

4: What issues exist with more modern exporters that prevent bridges from working properly?

I believe this is what ultimately stalled BC bridge modding. You can't export a new working bridge other than via Max 3.1.  The export functionality was never updated in later versions.   You can add/delete set elements in Niftools to create a new bridge .  I experimented with this on a few trial bridges (I'll try and find some images).   But I personally don't think it's ideal or as creative as the traditional method.

[Elijah]

Thanks for the response, I do understand that bridges and ships are different... but just trying to nail down exactly what the issue is. If I had to take a guess it is the way New exporters are handling exporting animation rigging?

[Lurok91]

I was and am still confused.  At the time BC came out waaay back then...  Max 3.1 was probably the go-to bridge exporter.  But other than that, I would have expected later iterations of Max to be able to export equally well?  So I can only surmise:  1) no-one bothered to develop a suitable working exporter (which I doubt) or b) there was some inherent restriction in BC that didn't allow accepting post 3.1 exports?

It is odd as creating bridges in later Max was super easy. But then you had to go through this ridiculous old-software rigmarole which seemingly had nothing to do with the game itself 

[Elijah]

I was and am still confused.  At the time BC came out waaay back then...  Max 3.1 was probably the go-to bridge exporter.  But other than that, I would have expected later iterations of Max to be able to export equally well?  So I can only surmise:  1) no-one bothered to develop a suitable working exporter (which I doubt) or b) there was some inherent restriction in BC that didn't allow accepting post 3.1 exports?

It is odd as creating bridges in later Max was super easy. But then you had to go through this ridiculous old-software rigmarole which seemingly had nothing to do with the game itself 

Well, it kind of seems that no one has made a BC specific tool (other than what the devs included in the SDK) and instead just piggy backed on tools geared for other gamebryo games... It seems that a reverse engineering of the BC NIF format is in order so that new tools can me made.

On another note:
How is bridge illumination handled? are there dynamic lights on the bridge sets? If so, how are they set up?

I did some messing around and noticed that if all of the 'lm' designated light maps are nulled out the bridge is just full bright without any shadows, so where is the light coming from? 

[Elijah]

A new thing has popped up today, I was messing around with the type 11 shuttle bridge in my BC project and noticed that the consoles on the back wall had very bad z face fighting. When I loaded up kobayashi maru later on (which has the same type 11 shuttle bridge) there was no z face fighting... I made sure the models were the same and they are.

My question now is what was done in kobayashi maru that resolved this issue? 

My BC project (consoles not looking so good)


Same bridge mesh in kobayashi maru, consoles looks fine 

[Lurok91]

On another note:
How is bridge illumination handled? are there dynamic lights on the bridge sets? If so, how are they set up?

I did some messing around and noticed that if all of the 'lm' designated light maps are nulled out the bridge is just full bright without any shadows, so where is the light coming from? 

I know you've prob read this in the modding guide but worth repeating:

Lightmaps versus nif lighting: it is possible to have a working bridge in game without lightmaps by exporting to nif with lights. Baz's TWOK bridge and I think a couple of others use this method. Lightmapping is more complicated and time-consuming and involves every single mesh element to be lightmapped. So why bother? Well again, it's a personal choice. Bridges with lights tend to be more uniform. Lightmapped bridges tend to have more light and shade as these are 'baked' into the nif.

There's often a default  light source in the exported nif even if you don't use lightmaps.  The pic below is one of the KM bridges (FC Excelsior?) which I think I imported nif into the version of Max I was using (not 3.1), changed some of the assets and then I think I exported out of Max as a nif without going through 3.1?   This is what I posted at the time:

Good(ish) news... cracked exporting prob.  The imported FC nif had all objects named as Editable Mesh.  So what I (or someone with any Max ) has to do is just rename objects as "Floor", "crew chair", etc... then should be able to export to ingame nif with original FCEx textures/maps!  (in theory at least, lol).    Any new objects like helm and chair will have to be textured separately.   But at least don't have to redo entire bridge.

[Elijah]

A new thing has popped up today, I was messing around with the type 11 shuttle bridge in my BC project and noticed that the consoles on the back wall had very bad z face fighting. When I loaded up kobayashi maru later on (which has the same type 11 shuttle bridge) there was no z face fighting... I made sure the models were the same and they are.

My question now is what was done in kobayashi maru that resolved this issue? 

My BC project (consoles not looking so good)
[snip]

Same bridge mesh in kobayashi maru, consoles looks fine 
[snip]

Okay, resolved this issue, for whatever reason you must swap around  your display devices after the game is launched to fix the 'jaggies'. This is an issue with the graphics engine of BC not updating properly or something I would assume, this issue occurs in the 1.1 stock build and can be resolved the same way. KM 'fixes' the issue by just having a script automatically swap around your display device at boot.

(also, this graphics option switch around thing will likely cause your game to crash if you have SLI graphics, or some kinda of setup where you have two graphics cards)

[Elijah]

New question:

when changing from green alert to red alert, what is changing the lighting on the bridge? Like, what script or mechanisms is change a bright bridge into a dark bridge with flashing red lights?

[Lurok91]

Mario is the most knowledgable here on script functions, but I vaguely recall alert states are in BridgeHandlers.py, which calls on the main App.pyc.   

The physical alert states are changed  two ways:  the custom bridge script in Autoload, which allows map-swapping.   And via Gamma and Red Alert nodes in bridge nif (I believe this is what darkens the bridge. And creates the red glowing walls in bridges without light maps).

I also found this is in the SDK.   

Bridge models were built and textured in Max 3.1, much the same way as the ship models were. They were then brought into Lightscape (an architectural rendering program), which has a radiosity renderer that Max lacks. We were able to apply more realistic lighting than in Max, which allowed getting good vertex coloring and (with some specialized tools) generate light maps to be applied across sections of the model (floor map, wall maps, roof map, etc.). Theoretically you could use this to "bake" shadows into the existing texture maps, but this tends to make for large maps where you would be better off tiling a small map with a shadow pass separate. When bringing models into Lightscape, the bridge models had to be completely "bulletproof". That means no double faces, un-welded vertices, etc. Lightscape always seemed to find these glitches and magnify them since it tesselates the mesh when it renders and would produce some unpleasant results. It was not the most streamlined process, but the final results looked good. Many small and somewhat throw away tools were designed for solving minor problems on each of the bridges that looking back don't make sense to release. These tools had to do with the fact that Lightscape doesn't preserve the hierarchy of the Max model, and so we had to make a tool that took the heirarchy of a non-Lightscaped model and graft it onto the Lightscaped model exported as a hierarcy-less .nif file. There are also special organization issues and naming issues needed to get the lightmaps to dim and brighten for red alert lighting, as well as other maps to glow and flash (red wall lights).

Both bridges in the game were in the 4000+ poly range not including character and chair models.  We experimented with 2000, 3000, 4000 poly to get the best look and not over burden the graphics engine.  We don't recommend focusing on bridges for most mod folks as they were very difficult to do -- but would love to see what those dedicated fans come up with.

[Elijah]

So I have been looking on a few bridge models and have been seeing the NIF data block 'NiMultiTextureProperty' pop up a lot... but it is confusing me...

so the way I think it is supposed to work is like a multi-material in 3ds max. You have one multi-material that has several sub materials, once the multi-material is applied to a model the sub-materials would be applied to their specified regions (for example a multi-material could have the bitmaps for both the saucer and star drive of a galaxy, and you would only need to apply the multi material to the entire model for the sub-materials to be applied appropriately)... however... it seems BC is not using this block class like this at all because most of the time it appears empty or only has one sub material making it the exact same as a regular material

In modded bridges I have also seen it used a lot... so maybe someone who has made a bridge in the past can shed some light onto this mystery for me as to how it is being used

I can only guess that it is done so that bitmap tiling can be done and there is just no other way to do it?

[Lurok91]

As someone who modded bridges I really don't know all the connections between the work created in Max and the exported NIFs (other than obvious things like Gamma and Normal states).   I'd need to reverse-engineer one of my bridges.  But I suspect you're on the right lines as a multi-material...

This is an interesting post from cordilanus in 2012 - it's about ship models so may be worth posting in section also:

As some of you are aware, in the Screenshots thread...I have posted some pictures regarding fake bump mapping.  I have outfitted DJ's Galaxy with Grayscale Psuedo Bump Maps that were made from the speculars, just for me to show this thing off.

Now, this texture is completely separate from the base map "enterprisehull1.tga".  This is applied through a NiMultiTextureProperty in the Nif Model using Nifskope.  There are 5 slot elements in the NiMultiTextureProperty that is added, only 4 of these can be used in BC.  The fifth slot instantly crashes BC.

Slot 1 = Decal (Unconfirmed) - [ I usually link this slot to the base texture found in the NiTexture node ]
Slot 2 = Decal (Unconfirmed)
Slot 3 = ???  (Can't get it to show)
Slot 4 = Glow Map
Slot 5 = Unused, immediate BC crash

The bump maps are applied on top of the base map but does not override the other colors since the map in the 2nd slot does not have any color...just grayscale.  I have not confirmed if this works on other ships with different base colors.  Klingon = Green, etc...

http://www.bc-central.net/forums/index.php/topic,9034.msg184737/topicseen.html#msg184737

[Elijah]

As someone who modded bridges I really don't know all the connections between the work created in Max and the exported NIFs (other than obvious things like Gamma and Normal states).   I'd need to reverse-engineer one of my bridges.  But I suspect you're on the right lines as a multi-material...

This is an interesting post from cordilanus in 2012 - it's about ship models so may be worth posting in section also:

http://www.bc-central.net/forums/index.php/topic,9034.msg184737/topicseen.html#msg184737

This is not exactly what I was expecting, but is very intriguing! We will definitely be looking into this, thank you for bringing it to my attention. If there are any other posts from back in the day with info like this, please post it!

[Lurok91]

You might like this:

I assume you also know about this?

I was looking through the SDK, and just curious why the STBCExporter.dlu in Tools (the Max plugin) doesn't work with later Max versions than 3.1.   Or does it?   Has anyone tried?   All the ArtInfo doc says is * Models were exported using the STBCExporter plugin (STBCExporter.dlu placed in Max's "plugins" folder). Be sure "export textures separately" and "keep original texture names" is checked *