Unifying the Starport Mesh

[MechWarrior001]

So I started looking at the Star-Port mesh (mun_all_starport_s01_u01_r0_mesh_l0) and I noticed how the interior is broken up into several segments. I'm wondering if it would be better to merge this all into one solid self-contained mesh as opposed to the starport being composed of separate unconnected meshes that make up the shape of a staport.

What do you guys think?

 

[rosuto]

The client has a hard time when it tries to suddenly load complex models over 500k, thats why it is broken up into smaller chunks. Pretty much imagine you are a crafter making a mad dash into coronet while being chased by a butterfly. Suddenly your game freezes for 3 seconds while it tries to load the starport and then you find yourself dead once it unfreezes.

 

[MechWarrior001]

The client has a hard time when it tries to suddenly load complex models over 500k, thats why it is broken up into smaller chunks. Pretty much imagine you are a crafter making a mad dash into coronet while being chased by a butterfly. Suddenly your game freezes for 3 seconds while it tries to load the starport and then you find yourself dead once it unfreezes.

Hmm, that explains why my personal light doesn't cross over into separate rooms and hallways of the starport.

I've noticed some UV irregularities on the interior; We could probably re-texture it as one large mesh in max then re-export the individual pieces to the client.

 

[rosuto]

Its not a texture issue but more of a coding issue. Dynamic lighting is only rendered on certain pixel/shader files and most indoor objects do not use the those files. So one choice is to recode the pixel/shader files to use dynamic lighting. The other is to edit the sht file so it can access the pixel/shader files that do render dynamic lighting.

 

[MechWarrior001]

Its not a texture issue but more of a coding issue.

I never said it was a texture issue, I said I noticed some UV errors that could use fixing.

Each room has different UV maps for the floor texture, and for the most part these UV maps don't match the others in the other cells. Consider the following picture:

Spoiler

Notice the line of mismatched texels? What I'm saying is we can fix this if we import the cell meshes into an editor and redo the UV maps at the same time, as opposed to mapping each cell mesh individually (which I'm assuming SOE initially did which caused the problem).

Dynamic lighting is only rendered on certain pixel/shader files and most indoor objects do not use the those files. So one choice is to recode the pixel/shader files to use dynamic lighting. The other is to edit the sht file so it can access the pixel/shader files that do render dynamic lighting.

You're misconstruing the point I'm trying to make. From the behavior I've seen exhibited by the in-game personal light, it seems dynamic lights are hard-coded to not crossover cells. Ie. stand next to a cell boundary with your light on, and it won't illuminate the next until you formally step into it. Consider the second picture:

Spoiler

Notice how the light in the hallway does not illuminate areas around the hallway entrance in contrast to light that has bounced with GI?

 

[rosuto]

Sorry, I thought both were related to the personal light. I also remembered something today I did on accident while trying to figure out how to export msh files from 3ds max. So the client renders things in different "worlds". Everything outside renders in the outside world and if you cut a hole in a building, you can see right through it, but not inside it. Each room inside a building is its own world also.

So lets say I take foyer 2, and 3 of the starport and stitch them to foyer 1 msh file. I then go through and erase everything in the foyer 2 and 3 msh files. Still have to keep them because the server says so. Boot up the game. As long as Im in foyer 1, the personal light will render into the stitched portions of foyer 2 and 3. But as soon as I cross over into what the server says is foyer 2, the stitched room disappears and now I'm standing in the erased foyer2 msh file room. I can still see into foyer 1, but the stiched room is gone until I go back to foyer 1.

So how does the game determine when it should generate a new "world"?