Same deal with Rhino3D models. It's be great if this was fixed.Caydr wrote:...Zaphod I hope you're aware that units are ALSO flipped. On the X-axis, I mean. For instance, say I make a unit with a radar dish on the left size in max, when I put it in spring, the radar dish is on its right side.
Test build of new spring version
Moderator: Moderators
Err, huh? Rhino has nothing to do with it. It's like the whole jpeg vs bmp thing in mapmaking... it doesn't matter, the end result is an entirely different format.
That said, Spring does mirror 3do corpses across the Z axis (from the unit's front to rear), at least sometimes. The actual units display fine, but the corpses are flipped. Go kill a barracks in SWTA to see what I mean. I've never paid attention enough to know if it does it for all corpses or not.
That said, Spring does mirror 3do corpses across the Z axis (from the unit's front to rear), at least sometimes. The actual units display fine, but the corpses are flipped. Go kill a barracks in SWTA to see what I mean. I've never paid attention enough to know if it does it for all corpses or not.
Maybe I should clarify my statement. Models built in Rhino3D appear to be mirrored from left to right in UpSpring, and although most units do have left/right symmetry, if you were to build something that had left-right assymetry (such as the Orion), then the gun would appear on the opposite side of the model. Another example would be the Elemental in BattleTech, which has a different weapon on either arm. For the sake of authenticity, I would have to mirror the unit before importing it into UpSpring so that it gets mirrored again into the correct configuration. It may seem to be splitting hairs, but it is not much different from the problem with inverted faces on features, which was deemed important enough to fix.
When I made my commander statue model feature, in 3do builder it was fine, but when I put it on a map in spring, it was mirrored across the z axis (left to right), compared to the commmander in game. But that was only for features. Now I could be wrong, seeing as I used the Evola model, and thats the one used ingame, and both arms are fairly indenticle. **Nope just checked with both 3do builder and Upspring, it only applys to features. I tryed the commanders models I have and they appear as they would ingame. Heres my example:
3do builder & Upspring give me this:
http://www.maj.com/gallery/3dbricks/TAS ... statue.png
But spring gave me this:
http://www.maj.com/gallery/3dbricks/TAS ... fliped.jpg
**P.S. Zaphod, Upsring can see object parts in 3do files that show geometry, but don't show up in the list in 3do builder. Its some sorta glich that 3do builder has. Upspring really helps in that regarde to clean things up**
3do builder & Upspring give me this:
http://www.maj.com/gallery/3dbricks/TAS ... statue.png
But spring gave me this:
http://www.maj.com/gallery/3dbricks/TAS ... fliped.jpg
**P.S. Zaphod, Upsring can see object parts in 3do files that show geometry, but don't show up in the list in 3do builder. Its some sorta glich that 3do builder has. Upspring really helps in that regarde to clean things up**
-
colorblind
- Spring Developer
- Posts: 374
- Joined: 14 Mar 2005, 12:32
[quote="colorblind"]The build runs fine if I rename all the AI dlls,[/quote]
This may be because the ABI broke somewhere between the latest windows only release and this platform independent release. Though I'd expect it only matters if you try to use the AI...
To devs: I think we need a policy of some kind regarding ABI compatibility, because broken ABI has already given me a headache when trying to port 1.06 of OTAI to linux...
And AI devs should #include files directly from rts (ie. add trunk/rts, trunk/rts/System and trunk/rts/ExternalAI to include path) instead of copying them. That 'd guarantee API compatibility at least... *sigh*
This may be because the ABI broke somewhere between the latest windows only release and this platform independent release. Though I'd expect it only matters if you try to use the AI...
To devs: I think we need a policy of some kind regarding ABI compatibility, because broken ABI has already given me a headache when trying to port 1.06 of OTAI to linux...
And AI devs should #include files directly from rts (ie. add trunk/rts, trunk/rts/System and trunk/rts/ExternalAI to include path) instead of copying them. That 'd guarantee API compatibility at least... *sigh*
Isnt that how ti works already? JCAI and NTAI are the two abse setups that most other AI projects are absed on, even if all the code has been torn out, it usually ends up with the base VS project files, the interface, adn the basic cglobalai structure intact, possibly under a different name, with a new AI built ontop.
I believe the onyl exception to this was OTAI which started that way then shfited because veylon had troubles getting std classes working witht eh itnerface on his machine
I believe the onyl exception to this was OTAI which started that way then shfited because veylon had troubles getting std classes working witht eh itnerface on his machine
-
colorblind
- Spring Developer
- Posts: 374
- Joined: 14 Mar 2005, 12:32
I did some more testing:
On my computer at home (which has a geforce 5200) the waterline isn't jagged at all. It was jagged when I tested it on an MX 440.
Furthermore the "cmds 1000 res" script doesn't wait for connections anymore, and using XTA the Arm advanced k-bot lab has a white buildpic in the lowerright corner, which will crash Spring if you click on it. Looks like the mod isn't correctly parsed ...
On my computer at home (which has a geforce 5200) the waterline isn't jagged at all. It was jagged when I tested it on an MX 440.
Furthermore the "cmds 1000 res" script doesn't wait for connections anymore, and using XTA the Arm advanced k-bot lab has a white buildpic in the lowerright corner, which will crash Spring if you click on it. Looks like the mod isn't correctly parsed ...
