Upspring 1.54
Moderator: Moderators
http://user.supradigital.org/jcnossen/U ... r-1.54.exe
Changes for 1.54
- Texture image handling rewrite,
this fixes the reduced image quality of textures in previous versions.
- Added new mode of normal calculation, which allows a maximum smoothing angle. It seems to work, however sometimes generates more unique normals than I think it should...
Changes for 1.54
- Texture image handling rewrite,
this fixes the reduced image quality of textures in previous versions.
- Added new mode of normal calculation, which allows a maximum smoothing angle. It seems to work, however sometimes generates more unique normals than I think it should...
This RULES. It soooo beats having to set this all up by hand, especially since it can be done by Piece.
Before:
After:
... soooo cool.
"but wait, Argh, this won't matter so much, with shaders and textures on the model, right?"
No! This can radically improve your models' looks! Watch!
Before:
After:
... finally, after what, about 10 months... the Lord looks like it was meant to, with curves and smoothness combined with sharp edges. Fricking fantastic!
Before:
After:
... soooo cool.
"but wait, Argh, this won't matter so much, with shaders and textures on the model, right?"
No! This can radically improve your models' looks! Watch!
Before:
After:
... finally, after what, about 10 months... the Lord looks like it was meant to, with curves and smoothness combined with sharp edges. Fricking fantastic!
Modelers are happy when the renderer accurately reproduces their work. This latest change means that what we model, we'll see in Spring- without so many compromises.
Still don't believe this is the greatest thing since sliced bread? Check this out... maybe 45 minutes of work, an a huge difference in the quality of the way the models look in Spring, especially units like the Springer, which always looked like crap before...
Still don't believe this is the greatest thing since sliced bread? Check this out... maybe 45 minutes of work, an a huge difference in the quality of the way the models look in Spring, especially units like the Springer, which always looked like crap before...
). Aside from that, great tool in the baseline 3do->s3o converter.
I am not sorry, I strongly disagrea.MadRat wrote:The texture handling on the conversion is definitely better and uses texture map space a lot better, too.
do you use only unique textures on your model? Does it only store part of the uvmap that it is using?
No, it WILL store several textures with high levels of redundancy. It will have ample wasted space. Not better texture space. It will better usage when you think about it.
for example say you used corcamo01 on 10 models... and guess what that means buddy? You now have 10 copies of it floating around.
-
Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
s3o is only better when you UTILIZE it.
this is just cannonball to a fly.
s3o is better for the usage of glow maps and the better smoothing operations. When you uvmap a model you layout and draw the texture in a way that reduces stretching and makes good usage of texture space.
3do is handy because you have VERY detailed textures for what texture space you are using but you lose glow map and control of your normals along with obvious texture stretching.
this sort of conversion does not make the model suddenly laid out in a way that is good or really that smart as it were. Argh would area with me on that. You should know my objection is not one about texture space, frankly I think we have ample. However, I am a huge proponent of proper textures with good detail to them.
This conversion will NOT fix texture stretching. The user will now have to do a glow map and reflective map as the old one is lost. While I think it is REALLY COOL that JC did this as an option and I can use it to fast prototype menoth, I am just trying to get those... less experience moders to realize that this is not some new and awesome thing with no negatives. That is all. Think about it forb... you are mapping all the faces to 1 texture with several copies of the texture on it... sort of a mini version of what already happens except now you have to redo the reflective map and you can do a glow map.
I CAN PROMISE YOU fang would prefer to uv over using this.
AGAIN, I am not saying I do not think it is cool but I am trying to help explain what you lose for the convenience.
this is just cannonball to a fly.
s3o is better for the usage of glow maps and the better smoothing operations. When you uvmap a model you layout and draw the texture in a way that reduces stretching and makes good usage of texture space.
3do is handy because you have VERY detailed textures for what texture space you are using but you lose glow map and control of your normals along with obvious texture stretching.
this sort of conversion does not make the model suddenly laid out in a way that is good or really that smart as it were. Argh would area with me on that. You should know my objection is not one about texture space, frankly I think we have ample. However, I am a huge proponent of proper textures with good detail to them.
This conversion will NOT fix texture stretching. The user will now have to do a glow map and reflective map as the old one is lost. While I think it is REALLY COOL that JC did this as an option and I can use it to fast prototype menoth, I am just trying to get those... less experience moders to realize that this is not some new and awesome thing with no negatives. That is all. Think about it forb... you are mapping all the faces to 1 texture with several copies of the texture on it... sort of a mini version of what already happens except now you have to redo the reflective map and you can do a glow map.
I CAN PROMISE YOU fang would prefer to uv over using this.
AGAIN, I am not saying I do not think it is cool but I am trying to help explain what you lose for the convenience.