Spring RTS Engine

WinXP 32-bit. Don't know if it's right or wrong TBH.

Also don't jump to assumptions. UpSpring doesn't even build 64-bit, it's a 32-bit app. It shouldn't behave any different. It could easily be a number of other factors.

SpliFF wrote:So what this means is that adding Collada support to Spring and UpSpring would make OBJ vs. 3DS an irrelevant issue. I only brought this up because I think that BOTH OBJ and 3DS are obsolete. Anyway, I realise this thread isn't talking about the future and no support exists in Spring/UpSpring for Collada yet so don't let me derail this thread.

Yeah - .fxb is a fine format although I'd think twice before making it the format for Spring. It imo stores too much info unimportant to Spring like light positions and things like that. It also will give you and the actual content developers headaches as there kinda regularly are compatibility issues when something was changed about the format - so prepare to do regular updates on the code for it...

To my mind the best solution would be either a direct import of like md3 models or whatever sounds feasible as a new model format or having some good tools for just importing the geomertry and do the rest in tools that save to a Spring friendly format. For the latter we'd probably need a facelifted Upspring and an animation tool for the to come bones system (while this also *could* be done via Plugins like the BOS one for Blender we have right now which creates the required code)...

Master-Athmos wrote:Yeah - .fxb is a fine format ...

AFAIK FBX (not FXB) is unrelated to Collada. The Collada extension is .dae and if the two formats are related in any way it must be historical.

Yeah of course .fbx - small typo. I thought this was the Collada extension but maybe I mistook it for Autodesk...

Argh wrote:Try this. It's very important to actually open UpSpring first; double-clicking on S3Os opens the oldest version usually. I just put a shortcut on my desktop. This is the last public build of UpSpring from jcnossen, and it fixed a bunch of things.

Is this newer than 1.54?

no

Sorry about the OT, but does anyone have a batch collada-to-anythingwings3dcanimport tool?

rattle wrote:I don't export as 3ds because it seems that wings' 3ds exporter unwelds vertices where seams are resulting in messy hard edges all over the place.

This apparently isn't part of wing's fault. Supposedly 3ds breaks all edges that are discontinuous on the uv due to some restriction of only one uv per vertex.

this is probably where the ugly mesh breaks are coming from on 3ds files.

That doesn't make any sense, though. When I imported your test model, it was preserved exactly as you set it up, all hard and soft edges were preserved.

I think the problem's with UpSpring, not the file format.

mmkay.

Just to confirm that, there's a shot of the side of the left shoulder- mixed hard and soft edges, same with the leg. I don't think there's anything wrong with the file specification at all.

If what you were saying was true, 3DS files wouldn't have become one of the four de-facto base formats just about everything reads and writes. There's just something buggy about UpSpring, is all. That doesn't mean there isn't a serious problem, ofc- but at least it means it could get fixed.

3ds is a legacy format. do you still see .ani? nope no one does it. yet we still use them for cursors.

Meh, OBJ is older than 3DS, lol, it's from the mid 1980's IIRC.

I have presented the information.

Feel free to find a nearby wall and argue with it.

I have presented proof that what you've said is incorrect. There's a bug in UpSpring. This is true. I see different results than you do, and that's what's causing these issues. You need to quit being so irrational about a file format. Being wrong about the cause doesn't mean there isn't a bug and that 3DS isn't borked for you. Now that we know there's a bug in the software, it needs to be addressed.

I don't really care, if it's fixed through fully supporting the OBJ specification, or by fixing whatever's wrong with 3DS support. Either way, it means one-stop imports, and not wasting time on tedious stuff that isn't necessary.

http://www.wotsit.org/list.asp?fc=2

file format specs, go read them

Also:
http://www.google.com/q=does+3ds+store+normal+data

A 3DS mesh does not store any normal data so normals must be computed by the target system.

The Unofficial 3DStudio 3DS File Format v1.0 (RTF) states that the format contains specific references to welding; I didn't see anything there to support your claims, and the screenshots I posted were from Smoth's 3DS.

Maybe under some circumstances UpSpring isn't handling the welding operation correctly- perhaps it gets the vert index wrong, or something. That might explain the welding errors Smoth showed earlier.

Broken welding may be upspring's or wings' fault, but the major thing is that 3ds doesn't store vertex normal data which OBJ does. I thought that's what this entire discussion is about.

According to 3D Studio File Format v0.93 (RTF):

The first three ints are the three vertices of the face.
0 stands for the first vertex defined in the vertex list.
The order has a purpose: to give the direction for the normal
of each face.
If you turn a screw (standard screw) in the way the vertices
indicate you will find the normal.

IOW, it doesn't store the normals in the same fashion OBJ does (explicitly) but implicitly, apparently. Probably the UpSpring bug is there.

.3ds stores smmothing groups not normals.

It breaks weilds where the uv map has a break see under side of back in my earlier picture.

Obj keeps the normals a fixed obj sub object import would solve this whole discussion