TMP Spacedock WIP (MESHSMOOTH PROBLEM fixed)

[Lurok91]

As a little sideline while doing Baz's Ent bridge, experimenting with TMP Spacedock.  Took stock Fed Starbase (with hi res/512 texture replacements),  added in docking bays and P81's Excelsior,  and did ifl anims for entrydoor lights.  Works ingame, but couple of issues:

Exported mesh has lost its smoothness (but looks ok in Max and in Nifskope).  Have tried all variants in Max but nothing seems to work.  

IFL anims working, but not very bright or clear ingame.  Not quite sure why.

Interior of dock (pic 2) is very dark when away from ingame light source.  Is this normal, or should there be a light inside model?  

And docking manoeuvre doesn't go to entry door (I think opposite side of base instead).   Probably a hardpoint error....

If anyone can advise, or wants to play with model/nif, let me know.  

[baz1701]

IFL anims working, but not very bright or clear ingame.  Not quite sure why.  

the trouble with animations is you cannot add the glow prefix after the file so you end up with light_glow1.tga, light_glow2.tga etc

So though the animation is working they are not being lit up.

As for the docking that is a HP problem  you have a docking start and stop points (or something similar) just edit them to the correct position in the MPE.

[Kirk]

In that case, you could modify the ship script to not require the _glow suffix and that may sort it. Just make sure that all of the textures have alpha channels, even if they're all black.

[Lurok91]

Thanks guys.  Glad someone finally able to offer useful feedback. And makes sense.   Kirk, how would I modify ship script to not require _glow suffix?   Oh, and I think all textures have alphas.

[Kirk]

In the file in scripts/ships change these lines:

Code: [Select]

pLODModel.AddLOD(pStats["FilenameHigh"], 4,  1000.0, 300.0, 0.0, 400, 900, "_glow", None, None)
pLODModel.AddLOD(pStats["FilenameMed"],  4,  5000.0, 300.0, 0.0, 400, 900, "_glow", None, None)
pLODModel.AddLOD(pStats["FilenameLow"],  4, 10000.0,   0.0, 0.0, 400, 900, "", None, None)[/codeto something like this:

Code: [Select]

pLODModel.AddLOD(pStats["FilenameHigh"], 4,  1000.0, 300.0, 0.0, 400, 900, "", None, None)
pLODModel.AddLOD(pStats["FilenameMed"],  4,  5000.0, 300.0, 0.0, 400, 900, "", None, None)
pLODModel.AddLOD(pStats["FilenameLow"],  4, 10000.0,   0.0, 0.0, 400, 900, "", None, None)

[Lurok91]

Thanks for tip Kirk.  Tried that, but sadly didn't work       Had a thought though: could problem be that i'm using texture_glow as both diffuse and self-illum, so cancelling each other out ?    I assumed textures wouldn't show up in game without self-illum channel.

Thought two:  I have the anim_glows as separate alpha_glows (so no diffuse texture).  How about if I made those the self-illum?

On hardpoints, would love advice.  Using Reliant, docking seems to be working now, but ship doesn't go far enough inside (just to end of 'landing strip').  I understand the principle of adjusting hardpoints in MPE (have done it many times) but on starbase quite tricky as the xyz's inside base and hard to see what doing.  

On a side note,  USSSovereign has kindly helped work out an 'animated spacedoors'  which works ingame (needs a little adjusting) and hopefully a trigger sometime soon.  

[Kirk]

All of your textures should have a r, g, b, and an alpha channel. So, if you separate out the diffuse and self-illumination maps into separate textures, they will not glow ingame.

[Lurok91]

Did experiment with separate glow self-illums. but no difference. However, while trawling BCC for possible ideas. came across this in LC's animated maps tutorial:

2 - I just can animate the diffuse or the glow using alphas not both simultaneously in one map. Don't know why.

So it's a recognised problem.   Hope may still find solution one day though...

[Bren]

Look at the Sov's animated bussards. The glowing layer is under the animated layer (iirc). Make the active lights in each frame of the animation transparent and place a glowing strip of polygons behind the lights, there may be a simpler approach, but that seems to be the approach everyone has taken to animate glows.

[Lurok91]

Have animated doors and working approach lights. 

Does anyone know why textures have checkered effect as in pic?   Look fine in Max, and NIFskope - only takes on this effect ingame. Must be something to do with lighting.

[Locke]

Sorry, I don't have any solutions for you, but I was just looking at this and wondering: why haven't there been any Trek episodes or books or anything that focus on Starbase 1 or it's descendants?  Its a MASSIVE structure!  One of the largest in the Trek universe, even dwarfing most Borg constructions.  I would just love to see some sort of serial comic or CG fan series focusing on this.

Anyway, just as a thought: are your textures in NIF format?  If so, could it be some sort of compression error?

[Morgan]

I think that "checkered" effect are actually smoothing errors on the model. I'm assuming you had to alter it in order to get your animated doors effect...

[Locke]

Well, that's no darn fun!  Although you did a fantastic job, it looks like you'll have to recreate the mesh with a higher poly count.  No amount of smoothing will get rid of those lines.  I suggest for something that size that you use a 64-sided object (cylinder, tube, etc).  I know that seems high, but it will be worth it in quality.  32 might work, but you'll still get some edging.

At least, this is my take on it.  You might try going around to some modeling websites and asking about subdividing.  I tried it on a cylinder I modified to be similar to yours, but I couldn't get anything that didn't look strange when I applied a modifier.  A last resort (or perhaps a fun time waster! ;)) would be to just go through the modifier list and see what each one does.  Play with the permutations and see what you can come up with.  Who knows, you might stumble on just the right tool to do what you're asking about.  Just remember to use a fresh copy and not save anything!

[Kirk]

It looked fine before, there's no need for a high poly rebuild.

[Locke]

Dur . . . forgot.  Reread the above posts and realized that this was ported straight from the game original.

In that case, I would say that it's something between NIFSkope and Max.  Some sort of import/export issue that you aren't taking into account.  Possibly the import process, since it would be where things would change the most.  Although I'm presuming a lot, since I know frak-all about NIFSkope or BC modding in general. :roll

[sovereign001]

that is extremely big!

[bankruptstudios]

What 3ds max are you using? If you would like to send it to me with the textures, i can take a look at it, the pic above looks like each panel from the rim to the top was smoothed by its self. You should select the hole dome from the rim to the top then smooth it to get rid of the lines.

[Bren]

From what you said in the opening post, it would seem you might have exported it with an omni light within the mesh...

I don't have any particular reason for thinking this, other than the fact that it is unusual to include a light in a Bridge Commander NIF... maybe that's causing some exporter foul-up. Try removing the light (if there is one) and re-exporting.

[Lurok91]

@Bren - no light in mesh.

In fact Baz did his usual great work and fixed mesh errors.   Still a few other things need to fix but minor.  May also need to rescale.

Doors open via Ftech (so red alert opens doors).  USS Sovereign @BCS said he'd write a script that could trigger doors open from bridge of ship (or proximity, not sure which)

[Kirk]

Hang on, why would you want the doors to open upon red alert? They should close to prevent any ships from flying into the sensitive bay areas.