Thinking about Lego system

[Treeform]

I am thinking about a lego system. Sort of between spore creature editor and spring kbots.

Here is an example:
A unit like this would be made of several smaller parts.


Each part would have some meta data associated with it how it should be used like if its a joint (yellow) or some thing that should be touching the ground (purple).


And each part would have loose block metadata at which the actual connecting would happen (green). Because connecting at geometry level would just not fit well.


Now that you have idea what i am talking about lets discuss how useful it will be.

Pros:

1. Parts would have to be made by 3d artists knowing what they are doing (and we have some good ones on the forums) but the units could be made by any one.

2. As number of parts grows more and more units could be constructed without having to model any thing. So less work for better models.

3. This will allow more experimentation from the the community. Don't like a unit? Add bigger/smaller guns to see how it effects. Need a unit for some task? Build it from parts.

4. It would make easier to conform to a style if they pretty much use same base parts.

5. Theoretical kbot editor could compute constraints for joints and guns and walking cycle based on join and block metadata.

Cons:

1. Units could look a bit cookie cutter.

2. Parts have to be made.

3. Spring engine does not support this.

4. There is no editor to put parts together.

What do you think?

[Hoi]

I actually thought alot about this too, and got some ideas, like a sort of robot wars 3rd person thing, you can buy your parts and customise your robot, ect ect, ranks, and all the bla bla, I'd be awesome, but take alot of time to get to work.

Doing this for a mod ingame would be hard though, and would prolly need engine changes.

[Argh]

3. Spring engine does not support this.

4. There is no editor to put parts together.

5. There is no automated way to script such objects.

6. There is no multitexturing approach currently available in the Spring engine (MD5 supports it, unfortunately none of that experimental code has been made available). You need multitexuring to make this work well.

Heck, if multitexturing was available, just for something like S3O, it'd be revolutionary, let alone a full-blown system like what you're proposing. It's one of the most fundamental building-blocks of modern content that's missing from the engine, frankly.

[Treeform]

Multitexturing is not a big problem. I think its best is to collapse the uv maps into one uv map in the editor. Most of this stuff will be done during the edit phase (joints and block snapping + motion and constraints computing) and produce standard spring S3O files.

[Hoi]

In theory you could "cut" a 512x512 map in 4 pieces and only use the left top corner for legs, right top for heads, ect, but I really suggest to wait for that multitexture stuff, it sounds alot easier.

[AF]

Discussion of the merits of this system is irrelevant and have been discussed and requested elsewhere. Instead we need to focus on implementation, but most precisely doing it in a way that can be re-used prolifically by the community for various other things.

[Argh]

You're going to magically combine objects into a final uvmap? That's nice... but I don't think it's terribly practical.

For example, what if we want to use stuff that's not a square? What if we're looking at a 512 output map (the highest size you typically want to use) and you have 17 mini-objects with 128/128 skins?

Moreover, that means that all sub-objects will have to be skinned to a very teeny-tiny spec.

What about big objects, that need more space to really look good? Usually, good practice is to give the largest areas of the model as much space as is practical... and that's frequently a non-square area. I can see a tradeoff here for modelers- figure out how to fit that big long skinny thing into a 512 / 256, for example... but I don't see a good way to reconcile that with a jigsaw approach- the real size needed for things is mainly determined by scale. If you scale up some legs to twice their normal size, you're going to want to reskin them at twice their resolution, or use a different approach entirely to maintain levels of detail.

In short... I don't think this idea is worth pursuing, if you're not going to solve the main problem, which is that Spring needs multitexturing support, either via Lua or internal to the engine.

Solve that one, and a lot of things become possible, and I'd be more than slightly interested in building some content. But the idea of doing slap-together "modeling" with bits and parts with crappy resolution is just silly, imo- scale would make things look terrible.

Meh. You're the guy who said you had a 3DO converter that properly maintained the uvmaps, and then you dropped off the face of the Earth when I asked you to provide it, so I guess I'm done here until you actually show me something that works.

[Treeform]

Meh. You're the guy who said you had a 3DO converter that properly maintained the uvmaps, and then you dropped off the face of the Earth when I asked you to provide it, so I guess I'm done here until you actually show me something that works.

You right i dropped the ball on that one, here are the codez:
viewtopic.php?p=313658#p313658

None the less i think it is useful to think about Lego like system for building kbots even if spring does not have multi texture.

[AF]

didnt pressureline have units with various addons each with their own texture via lua?

[Pressure Line]

Correct. Then I got angry @ Lua. Very very angry, the bruises went away after a few days (my house has concrete block walls).

http://spring.clan-sy.com/wiki/Lua_UnitRendering

*shrug*

it is *possible* to do it the way i did it, but its certainly not user-friendly

[Wolf-In-Exile]

How will you animate something that's been pieced together like this, specifically? Sounds like alot of complex code work would be needed to generate procedurally, and the 'unit editor' moreso.

[AF]

tbh a purely lua based scripting format would vastly simplify the problem of implementation.

[Argh]

How will you animate something that's been pieced together like this, specifically? Sounds like alot of complex code work would be needed to generate procedurally, and the 'unit editor' moreso.

Well, the easiest way to go about it would be to declare that certain types of parts inherit a certain animation. Legs, for example, would be pre-built objects, with a certain walk-cycle that could then be tweaked for speed. Not a big deal. Turrets would get declared as to what weapon they are, and what arcs they cover, and the script and relevant weapon settings could be auto-generated from there.

Heck, just having an automated way to do that, with visual feedback, would be nice, period, and I'd use this thing for that if nothing else.

tbh a purely lua based scripting format would vastly simplify the problem of implementation.

It would and it wouldn't, imo. If we have to deal with a stock-standard S3O, I'd say stick with BOS. If we have some crazy multitextured beastie, then I'd say go Lua, it'd probably be faster.

[Pressure Line]

I had it set up so that the extra pieces would follow whatever they were attached to. Therefore it would be no more complex than scripting any other unit, since you would just use empty objects to control the extras. The only real issue for use is having to convert the models from .obj to .lua, meaning each individually animated piece has to be separate.

Same goes for units built using UnitRendering. But since thats just straight texture swapping it all goes in one .s3o and just has the texture 1 & 2 replaced by Lua, its a bit easier to use.

[Argh]

I had it set up so that the extra pieces would follow whatever they were attached to. Therefore it would be no more complex than scripting any other unit, since you would just use empty objects to control the extras. The only real issue for use is having to convert the models from .obj to .lua, meaning each individually animated piece has to be separate.

Oh, so you stripped the OBJ to build a display list? I forgot that OBJ is just a text file... so, basically, the v for the vertexes, vt for texture coordinates, vn for vertex normals, and f for the triangles?

Damn. I had no idea it was that easy until I looked at the file. No wonder OBJ is the most common conversion format. Why do you re-label it Lua, though, when you're going to want to strip it and build the display lists during initialize anyhow?

[KaiserJ]

hi tree!

i'm useless at coding, so i can't help... but the idea of customizing units on the fly reminds me of kustorion mod... have a peek if you havent seen it already.

* edit: fixed link. i fail at posting today, time to stop lol

viewtopic.php?f=14&t=14387&start=0

[Treeform]

Well the idea is not customizing units in real time ... i like my rts games fast!

The idea is to provide a better toolset for creating mods by providing easy to use part system for units. If any one can throw unit together more people will do that. More units could be built for experimentation purposes.

The idea of making units real time would be hard to balance ...

[Pressure Line]

Oh, so you stripped the OBJ to build a display list? I forgot that OBJ is just a text file... so, basically, the v for the vertexes, vt for texture coordinates, vn for vertex normals, and f for the triangles?

Damn. I had no idea it was that easy until I looked at the file. No wonder OBJ is the most common conversion format. Why do you re-label it Lua, though, when you're going to want to strip it and build the display lists during initialize anyhow?

trepan did all the foundation work. there is (or was) an obj-lua converter, the script i butchered (modeltest.lua was included in earlier versions [0.74 0.75 0.7])) loads a .lua file not an obj directly (although you could do that as well, i just dont know how)

i even had it set up to load the texture and attachment point using custom unitdefs. the only thing i couldnt get to work was specifying a certain model to load, that had to be hardcoded :/ i also never figured out how to get teamcolor or reflections working, although since the texture is RGBA it can have proper transparency.

*edit* for what i did 6 months ago, look here.

[FLOZi]

Well the idea is not customizing units in real time ... i like my rts games fast!

The idea is to provide a better toolset for creating mods by providing easy to use part system for units. If any one can throw unit together more people will do that. More units could be built for experimentation purposes.

The idea of making units real time would be hard to balance ...

Really not worth the hassle of creating a system like this for that. OTA content is there for those who want models and don't mind any legal qualms, Nanoblobz is there for those who do. And in reality most mods won't go anywhere without having content creators on team anyway.

[AF]

No lua is definately faster. The onyl reason lua animation si slower than BOS right now si due to the overhead of cob<->lua interface. Lua itself is likely orders fo magnitude faster if it interfaced directly with the engine and bypassed the cob virtual machine entirely.

This would allow for far more complicated animations bos would never be capable of, as well as removing the need for many hacks and allowing animations and gadgets to directly interact, and it looks like there's a lot of interaction necessary for something like this, the cob<-> lua itnerface requirements of this lego system would bog performance down quite badly if it were used to its maximum potential.