New Upspring version (1.2)

TA 3D · Post by **TA 3D** » 22 Nov 2005, 22:56

Zaphod, try using a standard file format code to make your plugins. Don't use Blender, as it requires Python to even make most of the import/export scripts to work anyways. I've tried using it before, but never could get it to work right. Just get a different but standard code and that should take care of the problems people are having for importing/exporting.

Post by **jcnossen** » 22 Nov 2005, 23:10

There is no standard file format code... there is just a bunch of formats that every editor loads in a different way...

Weaver · Post by **Weaver** » 22 Nov 2005, 23:10

Tried that, situation reversed. And the UV map is flipped upside down either way.

This way also makes the reflection map very odd.

Post by **jcnossen** » 22 Nov 2005, 23:20

Ok, I'm going to make one of those bloody features myself and work out all the problems once and for all

That'll also stop me from giving incorrect information about things like backface culling...

Weaver · Post by **Weaver** » 23 Nov 2005, 21:53

Ok a couple more things, if you do simple conversion of a 3DO model. The collision sphere is 2 or 3 times bigger than it should be. And all objects face backwards. I've been playing with the Arm Shooter, he appears to walk backwards and shoot backward out of the wrong end of his gun!

Zenka · Post by **Zenka** » 23 Nov 2005, 23:06

Weaver wrote: I've been playing with the Arm Shooter, he appears to walk backwards and shoot backward out of the wrong end of his gun!

That's a problem I've encountered as well. Easy to fix when you load the unit in a 3d editor and mirror the unit.

maestro · Post by **maestro** » 24 Nov 2005, 02:01

Hi, current upspring UV somehow doesnt work for me
whatever software I used to export, uv always messed up
So I send example for you, it is a 3ds box make with 3ds MAX
I also include the original 3ds MAX file, screen capture and the texture
so you can check why my neat dice in MAX goes all wrong in upspring

Also included in the mail is Upspring manual I made (can be an official one if you want)-- still very early phase as i never succeed uv-ing so far

Post by **jcnossen** » 29 Nov 2005, 02:32

Here is Upspring 1.0:

1.0 binary
Source code for version 1.0 (GPL)

A lot of new features and fixes:

- UV reading from OBJ files has been fixed
- Object transform code has been fixed, but I doubt anyone noticed that

- UV map viewer
- If both S3O texture are avaiable, the model is rendered like in spring.
- View settings can be saved and will be loaded at startup
- Rotating camera mode (default for 3D views)
- Useful new UV mapping feature: you can export the model as a single piece, UV map it in an editor and import the UV coordinates from the single piece back on the original model. This means you don't have to UV map every seperate piece.
- Polygon delete (Delete key), polygons can be selected when the texture tool is active, otherwise all selected objects will be deleted.
- Texture maps were read upside down, fixed now (weird DevIL library...)

Bugs (I found out about these after I uploaded to FU):
-teamcolor is not yet supported, it is always black.
-recalculate vertex normals won't do anything, if you need to recalculate them for some reason, re-save and load the model (vertex normals are always calculated when a file is loaded).

Maestro said he will make a manual for upspring this week (he showed me a part of it already), when that is done I'll include it and also fix the teamcolor thing.

And if anyone wonders how big the grid is, here is an image for reference:

Every square is 1 heightmap square in spring, and 8x8 units in spring world coordinates. An XTA LLT is 4x4 of those squares.

maestro · Post by **maestro** » 29 Nov 2005, 04:05

what is collision sphere ??
and what if i put box or pentagon or clay like maldeformed geometry or dont add colision sphere at all ?

Post by **jcnossen** » 29 Nov 2005, 12:45

The collision sphere is not actual geometry (not in terms of polygons and vertices at least), it is calculated by the 3DS max plugin or upspring how big this sphere is and saved to the S3O. This sphere is what the engine uses to calculate collisions of units.
I think this works properly now as well:

It's a test unit (armflash) from Yeha resaved in upspring.

This is what it looks like in upspring 1.0:
You see that the teamcolor is always black:

NOiZE · Post by **NOiZE** » 29 Nov 2005, 13:01

Awesome!!

Sean Mirrsen · Post by **Sean Mirrsen** » 02 Dec 2005, 18:09

Awesome, yes. But I have a plethora of problems with the current release. Firstly, the textures. Alphamaps on the first texture do not show up on the model until the second map is added, which is very weird at least. The textures never get reloaded on model load. You could have the file store both the filename, and the path, so that the editor could use the textures from wherever they are located. Next, the piece tree. I pointed out one problem to you in the PM, Zaphod. The editor needs to start up with one piece already created, like 3doBuilder does. Also, the "create empty" function should use the last available piece if no piece is selected, right now this leads to a crash. For some reason, trying to import an object or replace an object creates an object with a blank name. While the first, combined with the merge to parent function is rather useful, the second is not. Please fix. Also, we need some sort of indication of rotation angles, or some way to use defined numeric values to rotate an object, like in 3dobuilder. Next, you can select several pieces at once, but using some of the functions on them leads to a crash.
And, finally, can you please rewrite the editor with some other SDK, or at least remove the minimize button from the title bar? It's really frustrating to lose your work in interface bugs like that. Thanks in advance.

Post by **jcnossen** » 02 Dec 2005, 20:04

You could have the file store both the filename, and the path, so that the editor could use the textures from wherever they are located.

That would require a new s3o version...

the "create empty" function should use the last available piece if no piece is selected, right now this leads to a crash.

Ok sorry, that is fixed now. Somehow I didn't add it to my todo list...
I think starting the editor with one piece in it already is not really useful though, in 3DO builder units needed to have a groundplate, but that is not necessary in spring anymore I think.

Next, you can select several pieces at once, but using some of the functions on them leads to a crash.

Which functions?

And, finally, can you please rewrite the editor with some other SDK, or at least remove the minimize button from the title bar? It's really frustrating to lose your work in interface bugs like that.

I understand it is irritating but I'm not sure if I can fix it, changing SDK is not an option. There is somewhat of a workaround though, press F2 to load your default view configuration.

Post by **jcnossen** » 08 Dec 2005, 02:06

New version 1.1:
http://www.fileuniverse.com/?p=showitem&ID=1970

Changes:
- Reflection and self illumination channels are now being used in rendering s3o's, if there is a second texture avaiable
- Fixed add empty bug reported by Sean Mirrsen
- Rotation type-in (degrees)
- FLTK Minimize bug worked around, so views keep the same size when minimizing
- Object center, radius and height can be set with the Model tab and are displayed in the viewport (optionally).
- Channel selection viewing in the UV/texture map viewer
- Selection mask improved.
- Example teamcolor selection
- Flip all polygons (of selected objects)

For some reason, trying to import an object or replace an object creates an object with a blank name.

I tested it and it already worked fine, you must be doing something wrong.

Sean Mirrsen · Post by **Sean Mirrsen** » 08 Dec 2005, 11:06

Just tested it in the new version. It still works the same way.

If you select an object, and then "Insert object from file", a new object is created with a blank name, with the selected one set as parent.

If you select an object, and select "Replace object (keep child objects)", the selected object is replaced for an object with a blank name.

I'm running on WinXP Home, if it helps ye.

maestro · Post by **maestro** » 08 Dec 2005, 11:32

Sean, it can be Lightwave dont export object properly when convert model to obj......
You should bug Newtek for that, not Zaphod

Beside that is not a big problem, rename is easy....
I have include that 'feature' in my SpringModel tutorial (unreleased beta today).....

Post by **jcnossen** » 08 Dec 2005, 18:49

The OBJ format doesn't support objects, so they don't have a name either.... the problem is more in the OBJ loading I guess..

Caydr · Post by **Caydr** » 08 Dec 2005, 21:59

Thanks for fixing the object origins, I'll see how it goes. I think that now, ultimately the only other feature Spring *needs* for GEM to work perfectly is custom collision boxes. I'm hopelessly ignorant of how much work that would be, but could you give an estimate how much time it will take before that's working? I was hoping to finish a beta by sometimes in February, but without this engine feature it won't be really playable.

Actually, it may not be totally necessary... um... I think it will be.... er... Ok, what exactly do the collision boxes do? Like, are they mostly for movement issues, like, to prevent units from moving through each other, or are they also used to detect weapon impacts?

If they're used for detecting weapon impacts, GEM is going to be held back. If they're used only for pathfinding and unit collisions... not sure... I might be able to work around that somehow.

Ultimately what I need is to be able to drag a bunch of boxes around by ships and use them as the collision detection. Otherwise the largest ships will be silly... I'm sure youc an imagine. Weapons impacting on spots nowhere near the model and that sort of thing.

I think that should be a high priority, I mean, if ultimately the goal of Spring is to create an open-sourced RTS engine (as the sourceforge description states I think), it needs to be good for things that aren't basically square.

This is in the wrong place, but do you suppose it would be possible to add engine flares? Basically I'd just need to be able to tell the engine to have a flare of X proportional size starting at Y invisible object, same as firing points. I could use the same engine flares as heavy rockets use. Not really important, but I wonder if it's possible.

Sorry if this is coming out unclearly, I didn't sleep well.

Post by **jcnossen** » 08 Dec 2005, 23:33

Actually, it may not be totally necessary... um... I think it will be.... er... Ok, what exactly do the collision boxes do? Like, are they mostly for movement issues, like, to prevent units from moving through each other, or are they also used to detect weapon impacts?

Everything is sphere right now... I think I can add collision meshes for weapon impacts though.
Pathfinding will still use spheres, that is not going to change.
It will be a lot slower though, so it can only be used for large and rare units.
As for priority, don't you thing a multiplatform spring version has a higher priority?

The flares: it should be possible to do that in a new scripting system, which will take a few months at least. I basically can't give any date on that.

Sean Mirrsen · Post by **Sean Mirrsen** » 09 Dec 2005, 00:38

Mesh weapon collision won't be too much slower with low-poly meshes used for those purposes. I mean low-poly as a very basic outline of a unit, much like hitboxes in CS, only even less detailed.

Spring RTS Engine

New Upspring version (1.2)