[ION3]

Geometry considered complete. Any complaints/suggestions? Any ideas concerning texture work?

@VA: You're doing the poseidon? Does the docking mechanism match your plans?

[attachment deleted by ninja]

[Mobius]

Glad to notice that you're using the texture as a reference. I would make it less bricky, if possible.

[MatthTheGeek]

It's a Terran cargo container, it's supposed to be bricky.

[FreeSpaceFreak]

@VA: You're doing the poseidon? Does the docking mechanism match your plans?

AFAIK, the latest and greatest Poseidon can be downloaded here, from the attachment.

[Kolgena]

Looks good. I can't see where any extra detail can be added in, except those thin yellow stripes down the centers of the sides. They *might* look a bit better if recessed a bit.

(Basically, I don't agree with the blocky-is-bad comment.)

[Turambar]

put some sweet little micro-bevels on those solid edges so they catch the light real nice.

[BrotherBryon]

Agree with the micro-bevels suggestion, I think it would offset some of the bland block surfaces nicely. It's looking really good so far but I do have one concern. This container docks with the Poseidon and the foot pads of the freighter have very little clearance with the retail container as it is. So those docking clamps you have protruding from the sides of the container may cause collision problems. You could sink those clamps into the side of the container and have them protrude out flush with the rest of the side.

[Galemp]

These cargo containers really need to be made in tandem with the associated freighter for maximum compatibility. See the Triton, Dis, and Chronos; they were all made as a whole by the same artist.

You should also, where possible, use the original textures/UV layout. It makes things a lot easier for everyone.

[ION3]

those docking clamps you have protruding from the sides of the container may cause collision problems

Good point.

You should also, where possible, use the original textures/UV layout. It makes things a lot easier for everyone

Why?  What about modifying the original textures, adding something in unused UV space?

I have a question about LODs. What if i do a screenshot of the container, resize it to 32*32 and add it to the LOD0 texture in unused UV space for use on the smallest LODs. Is that a good idea? Currently the container uses a second texture for the small LODs.

[blowfish]

If you're discarding the original UV layout, you're better off redoing (or remapping) the LODs to the new texture.

[ION3]

those docking clamps you have protruding from the sides of the container may cause collision problems

I just tested this and it is no problem. Looks like collision is turned off for docking.

[Dragon]

It is, there are numerous instances in which it's really obvious.

[Kolgena]

I recall docking with the Boadicia (or whatever the NTF base is) has an Elysium clip entirely inside a rocky part.

Can't remember what campaign though.

[ION3]

Changes since mvp_3_6_12:

New model from scratch (the original one was messy)
Added geometry for glowing dockpoints.
Added geometry for docking mechanism.
Changed plating slightly to make the design appear more modular. (the armor plates with the yellow markings are now about as big as the bare ones, so there are now fewer marked plates)

Removed glow from texturemap.

Lowered intensity of the glowmap.

Made the specular map (which was essentially a dark copy of the texture map) grayscale.
Made specularity of the yellow painted areas lower
Made holes for the docking pins shiny with a slight yellow tinge due to them being greasy.

Known problems:
Geometry does not fit Poseidon.
LOD table not yet changed. (might do a new lod1 model too)
Textures inefficient since the model uses a different texture for the lower LODs. I think I can put a small version of it on the main texture, as i doesn't need to be as big as the original as the distance at which that LOD is used is further than in retail.

Model with new textures attached as blender file and pof.
This is not yet finished.



Edit: I think i will change the normal map in order to account for the geometry change. DOES ANYOE HAVE THE SOURCE BITMAP?

[attachment deleted by ninja]

[ION3]

Update:

Container now uses the same textures for all LODs.
all LODs done.
many texture and uv tweaks

[Kolgena]

Do we have microbevels?

[ION3]

Do we have microbevels?

Well, that`s what the normalmap is for. But that normalmap is really terrible. I may modify it.

[ION3]

Update:

Here is the current version as pof with tex as tga and blender file.

I'm wondering whether the model suffers from the normal map inversion problem shown in the picture. I can't check because normal maps don't work in FSO on my  PC. I wrote VA a PM about it, but everyone else is also invited to help.

[attachment deleted by ninja]

[Vasudan Admiral]

Hmm, because you have the same part of the texture used in several different places in different orientations, it basically means the computer cannot possibly win no matter what engine you're using.

The way I'd get around it in this case would be to chop the crate in half down the centreline in blender (front to back of the crate as it would appear in-game) because FSO will be able to handle correct(ish) centreline mirroring of the UVs, and re-map the UVs of every part via projection, ensuring you do NOT mirror or flip any part in any direction. You can only slide and rotate the UV islands.

A good way to imagine it is that each piece of the texture is cut out from a one-sided sheet of paper, and you need to stick these little pieces onto a cardboard model of the container. If you flip any piece over and stick it on (as you would get if you did any flipping or mirroring in the UV editor) then you obviously won't see the texture on the outside. So, you need to UV map it in the same way. Don't flip or mirror anything except for the centreline mirror I mentioned first, and you won't have any inverted normal maps.

Does that make sense? It's a bit of a tricky concept to explain.

[ION3]

FSO will be able to handle correct(ish) centreline mirroring of the UVs

Why? What does the direction of the mirroring matter?

And, does it also work in blender?


I've read somewhere, that uv faces just like trigons can have their normals flipped, solving this problem. And this would be what the big game studios do. Actually from a mathematical perspective that does make sense, and it does not make any difference that uv space is just 2-dimensional.

Actually though i don't get it. I guess there's some performance optimisation at work which gives us this issue, as I'm pretty sure i can calculate the shifted normal given the rgb values of a texel, trigon normal, the vector from vertex 1 to vertex two, and the vector from uv-vertex 1 to uv-vertex 2. The only thing that is influenced by mirroring is the trigon normal, but that can be changed with the flip normals command.