Hard Light Productions Forums
Community Projects => The FreeSpace Upgrade Project => Topic started by: ION3 on August 12, 2010, 11:55:26 am
-
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]
-
Glad to notice that you're using the texture as a reference. I would make it less bricky, if possible. :)
-
It's a Terran cargo container, it's supposed to be bricky.
-
@VA: You're doing the poseidon? Does the docking mechanism match your plans?
AFAIK, the latest and greatest Poseidon can be downloaded here (http://www.hard-light.net/forums/index.php?topic=56674.msg1396301#msg1396301), from the attachment.
-
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.)
-
put some sweet little micro-bevels on those solid edges so they catch the light real nice.
-
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.
-
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.
-
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.
-
If you're discarding the original UV layout, you're better off redoing (or remapping) the LODs to the new texture.
-
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.
-
It is, there are numerous instances in which it's really obvious.
-
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.
-
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]
-
Update:
Container now uses the same textures for all LODs.
all LODs done.
many texture and uv tweaks
-
Do we have microbevels?
-
Do we have microbevels?
Well, that`s what the normalmap is for. But that normalmap is really terrible. I may modify it.
-
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]
-
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.
-
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.
-
Hmm.
Aside from the normals problem that definitely exists right now, there seems to be some gimpy texturing going on where the diagonal surfaces join the corner parts to the center of the container. Looks quite stretched to me.
Also, I'm not quite sure I follow on how to put the microbevels on the normal map. I don't mean bevels on the plates on the textures. I mean bevels on the corners/edges of the geometry. It's being faked right now by the normal maps, but you notice that it isn't occluded properly at far corners (like POM would do), so it wouldn't be as effective as a dozen extra polies to model in the edge bevels.
-
So add the dozen extra polies. You can certainly afford it.
-
It's being faked right now by the normal maps, but you notice that it isn't occluded properly at far corners (like POM would do)
I can't quite follow you. Which edges of the geometry are we talking about?
What do you mean with occluding? And what is POM? What do you mean with a far corner? Like when seeing the container from afar? Also, could the problem be the currently very bad shape of the normal map?
some gimpy texturing going on... [] looks quite stretched to me.
Are you talking about the image in the first post or the included file in my last update? Cause i redid the whole UV-mapping in between.
-
You can spend more polys on the edge corners to catch the light. On your version each of those blocks with nine dots = 18 polys.
(http://i229.photobucket.com/albums/ee67/waternz/mesh/bevel-contain.jpg)
-
I you look at the textures, there's actually on of those black, non-reflective seams right at the edges. I tried some experiments with normalmapping jesterday and i guess you're definitely right in that a bevel would be needed to get those reflections right.
Regarding the normalmapping problem:
http://forums.cgsociety.org/showthread.php?t=559283
http://www.torquepowered.com/community/forums/viewthread/99887/
http://www.bencloward.com/tutorials_normal_maps10.shtml
In all of these links there's mention of a possible fix for it. There are mentions of engine side fixes, but also of a fix in the model exporter. Maybe smething similar could be implemented in PCS2?
-
I you look at the textures, there's actually on of those black, non-reflective seams right at the edges.
In all of these links there's mention of a possible fix for it. There are mentions of engine side fixes, but also of a fix in the model exporter. Maybe smething similar could be implemented in PCS2?
Those black seams are on a 128x512 texture from about 1999. What you want to do, is think about what they might have done if they had used a larger 512x512 texture. Thing is they had to sell the model using just a small diffuse map, you on the other hand have a bit more choice with normal and shine maps, more polys and larger textures.
There really isn't a normal map problem. What you see in Blender with the inverted uv's is not what you see in FS. There are issues with seams, but that's across all applications. The standard rule for Hi poly > Lo poly baking is hide the seams as much as possible, and try not to have mirrored uv's next to each other. If you are using photoshop to create normal maps then you have a bit more choice.
Don't let the uv part put you off.
A good method is to sort the low poly model first, including smoothing. Normal maps and smoothing work together.
Then unwrap, either 5122 or 10242 The format of the current unwrap is a bit limiting, preventing you from getting much more detail in the map. Blender's unwrap tools are very good.
Create a hi poly version for baking OR use photoshop to create the normal map
A third way is to use the high poly for the larger details and photoshop for the smaller details.
Then use the normal map as a guide to create the diffuse texture.
An example, basic mesh
(http://i229.photobucket.com/albums/ee67/waternz/mesh/cm-rear1.jpg)
Normal map using xNormal for hi>lo and hight map to normal map. Both combined in Gimp to create one map. Even without the diffuse map it looks half way done already.
(http://i229.photobucket.com/albums/ee67/waternz/mesh/cm-rear2.jpg)
This is some of the hipoly parts. The colour coding is to help with the baking. Only one of each duplicated item is baked, since they all share the same texture space. The same sort of thing you would do for the container. A large amount of the container map is repeated to cut the texture space to the bare minimum.
(http://i229.photobucket.com/albums/ee67/waternz/mesh/cm-rear4.jpg)
XNormal has a some tools to convert normal map into a sort of fake ao. (Don't use a greyscale version of the normal map directly in the diffuse as it'll fight against what the normal map is tying to achieve) After that it's a case of adding colour and dirt. Having the normal map helps a lot with the texturing. Blender can also create an AO map to lightly shade the crevices.
-
What you see in Blender with the inverted uv's is not what you see in FS
That's good. I came to that conclusion from reading other threads around here. I suggest adding it to the tutorials that are floating around somwhere in the forum.
There are issues with seams, but that's across all applications.
If the model and normalmap are done right there shouldn't be any seams as far as i know. But people often have problems creating such "seamless" normal maps. Ore is there something else going on?
I'm currently not planning to make new diffuse, glow and shine textures, but we'll see. I did some changes to them, though. Currently I'm working on a new normal map using baking.
-
Err, there seem to be a lot of subdivided edges in your mesh which should be merged to save polygons.
-
there seem to be a lot of subdivided edges in your mesh which should be merged to save polygons
I already waited for that one ^^
Three reasons why not:
1. Vertex lighting quality for those who still use it.
2. The textures have some weird stretching which can be corrected that way. (granted, not in all cases)
3. The amount of polys doesn't change much if they are merged.
But I definitely see your point.
-
I'd very strongly recommend merging co-planar faces, yeah. ;)
1) Anyone still on vertex lighting has far bigger problems than an ever so slightly less cool lighting setup on one particular cargo crate, so definitely don't worry about that - they would much prefer maximum efficiency polygon wise anyway.
2) Any stretching I would say should be corrected on the texture, and remaking this particular texture should be pretty easy and good practice. I'd highly recommend it. :)
3) The amount of polys difference does matter for a mass-used-object like a cargo container since it's #-extra-polys * #-of-containers in-game. Well spent polys are fine but co-planar ones aren't really well spent. So, I'd say take those extra polys and make some cool feature out of the slanted connections between the extruded corner 3 polys of each corner of the container. They've always been really bland and in need of greeble-love! :p
-
3 polys of each corner of the container
???
edit: got it
I'll do some vertex lighting tests to see how it looks ingame.