It's definately not easy, maybe I start with the normal version and create a good binding system to my code first. Mono's build system requires so many linux build tools that it's really hard to build it on windows.
But a lightweight mono is going to happen sooner or later (though probably not by me then), mono without the whole support class library would be a really cool way of doing scripting in an application.
lua.net, C#, Boo, ... there exists a mono/.net version of basically every popular scripting language, and they can all work together.
you probably know all this already, but it's still cool to sum it up:)
Tools/Utilities for Spring
Moderator: Moderators
-
PauloMorfeo
- Posts: 2004
- Joined: 15 Dec 2004, 20:53
Mono as in The Mono ProjectZaphod wrote:... mono supports a lot of different popular languages. ...
http://mono-project.com/Main_Page
?
If so, i think that the only fully working language is C#.
VB.NET seems to be broken and stuff. I hear in the mailing lists about Boo and some talk about J or something like that but i don't read those so i don't know what they are talking about that.
But maybe you are thinking of compiling with Microsoft's .NET (which has implemented many languages) and run the resulting common intermediate code with mono? That would work, right?
Yeah I mean the mono project.
A lot of of mono is WIP, I'm probably a bit too optimistic about the language support. However if libraries like Lua.NET only use Platform Invoke, they would be runnable on mono as well. Managed C++ is not supported, but I suppose Lua.NET isn't using that because Lua itself isn't C++ either (So there is no need).
I'm going to stay away from MS .NET and use the mono C API functions (mono_*), because then it would theoretically possible to use a lightweight mono version in the future.
EDIT:
Actually Lua2IL is written in C#, so both Mono can probably use it without change.
A lot of of mono is WIP, I'm probably a bit too optimistic about the language support. However if libraries like Lua.NET only use Platform Invoke, they would be runnable on mono as well. Managed C++ is not supported, but I suppose Lua.NET isn't using that because Lua itself isn't C++ either (So there is no need).
I'm going to stay away from MS .NET and use the mono C API functions (mono_*), because then it would theoretically possible to use a lightweight mono version in the future.
EDIT:
Actually Lua2IL is written in C#, so both Mono can probably use it without change.
-
jouninkomiko
- Posts: 436
- Joined: 26 Aug 2004, 08:11
I've yet to experience that bug personally, zwzsg, using Maya 6.0 and its built-in obj exporter. I just have to remember to mirror the unit across the x-axis (so it's facing backwards) before I export, so it faces forward in Upspring and ingame. I suppose that could just be an error on my part though. In any case, haven't had any texture problems, except for self-illumination not disabling shadows...
blender rules, its posible to make movies with it.
Gimp has the tools if you know to use them and have the time.
or you lack the $$ to buy any other commercial software.
(just counter propaganda to troll).
I really really wonder why zaphod is losing time in making from scratch tools for spring when he can try plugins for existing ones.
If im not mistaken making your own set of tools is expensive, compared to re-using existing tools, that are actually there.
... yet upspring seems needed as a basic put all toghuether tool.
forgive my ignorance.
Gimp has the tools if you know to use them and have the time.
or you lack the $$ to buy any other commercial software.
(just counter propaganda to troll).
I really really wonder why zaphod is losing time in making from scratch tools for spring when he can try plugins for existing ones.
If im not mistaken making your own set of tools is expensive, compared to re-using existing tools, that are actually there.
... yet upspring seems needed as a basic put all toghuether tool.
forgive my ignorance.
-
Tim Blokdijk
- Posts: 1242
- Joined: 29 May 2005, 11:18
zaphod, it this easy to do?BlueIce wrote:I was thinking about a 3ds max script to export animation for spring... it should be easy to be done and VERY useful because 3ds do all the work, you only need to export position and angle of each object for each frame...
the only thing is that s3o should support 3ds pivots...
-
jouninkomiko
- Posts: 436
- Joined: 26 Aug 2004, 08:11
are you talking about the =>3do exporter for (old) 3dmax?
there is already a functional s3o exporter for 3d studio. (ver 7?).
And thats a good point Zaphod.
aside my personal desire.
(that is taking open source apps an turn them to work for spring, tada! editting suit ready.).
Oh, and im most gratefull for upspring as i could not attempt to make units if its not for it. (im just ambitious, and lazy.. and.. agh.).
there is already a functional s3o exporter for 3d studio. (ver 7?).
And thats a good point Zaphod.
aside my personal desire.
(that is taking open source apps an turn them to work for spring, tada! editting suit ready.).
Oh, and im most gratefull for upspring as i could not attempt to make units if its not for it. (im just ambitious, and lazy.. and.. agh.).
Good grief! Nononono! Do not build an exporter, unless it's for something cheap, like MilkShape 3D. Don't build one for Max, for goodness sakes.
Reasons:
1. You will force me, and everybody else who doesn't have mega-$$$, to pirate Max.
2. It will probably be a very buggy thing- you'd have to translate from Max's coordinate/motion controls over to BOS. Better to do that in a cleaner, simpler environment that was purpose-built for it.
Basically, I think that's a terrible idea. It's a very non-Open Source way to approach this...
Reasons:
1. You will force me, and everybody else who doesn't have mega-$$$, to pirate Max.
2. It will probably be a very buggy thing- you'd have to translate from Max's coordinate/motion controls over to BOS. Better to do that in a cleaner, simpler environment that was purpose-built for it.
Basically, I think that's a terrible idea. It's a very non-Open Source way to approach this...
What you're saying is perfectly understandable, it's not a problem with translation. It's just a very bad idea. You may be happy pirating 3DS Max, but I am not.
Moreover, I haven't the foggiest how you're going to take things like paths from Max and turn them into BOS. BOS doesn't work like that.
Want something to do a loop? Gotta code the states that make it repeat.
We don't need IK, because we're not doing polygonal deformations- just simple move / rotate transforms.
People who don't understand BOS don't get why we want to keep its strengths... and lose the weaknesses.
Strengths of BOS:
1. Parameterized, randomized or scripted transforms. You can program small variations in motion-over-time, or give a slightly new seed to a rotation's arc, to end up with randomized results that would be more organic and realistic. This is fairly impractical at the moment, because of some of the critical weaknesses of BOS, but it's quite practical if we have a visual timeline editor and playback viewer.
However, parameterized and scripted transforms are a snap. Tie into a game variable, a timed state, or anything else you want to set as a condition, and you can make things happen in perfect order.
With a visual editor allowing us to quickly do the "rough cuts" of individual motions, I can see us doing some very, very powerful stuff with this. Everything from having soldiers walk with a noticable limp if they've been wounded to having a building fall apart in randomized ways as it takes damage. Don't base your assumptions on what is already out there- we've been limited by a primitive editing environment, and have only so much free time.
2. Perfect precision. Want to speed something up by 10%? You can go through a series of NOW/SLEEPs and cut down the SLEEP time 10%. Very hard to do with traditional IK-based animation techniques- if you're lucky the animation still hangs together somewhat correctly, but will require lots of tweaking. Which is why people working in IK settle on timeframes very quickly, and then stick with them, and why games whose content is based around IK animations (first-person shooters are a great example) take so much effort to develop. Want to have the guns of every character in Counter-Strike: Source shoot twice as quickly, with perfect visual fidelity? Good luck on that one- it's not as simple as cutting the timeline in half. BOS doesn't have this problem.
3. Non-linear outcomes without source code revision. Because all animations are scripted, we can have more than one outcome path for a given event, either through slight random factors, or through multiple animation sequences. The possibilities here are tremendous.
Weaknesses of BOS:
1. BOS cannot GET/SET many of the game variables in Spring yet. This limits its usefulness.
2. No scalar transforms for pieces. This is an engine limitation as well as a limitation of BOS.
3. Poor editing environment. BOS is currently editable with one tool- Scriptor. Yes, there are other tools available, but most of them don't work as well.
4. No playback environment, other than the game engine.
Get rid of the weaknesses, and BOS + a game engine that supports it is a very strong animation environment.
Moreover, I haven't the foggiest how you're going to take things like paths from Max and turn them into BOS. BOS doesn't work like that.
Want something to do a loop? Gotta code the states that make it repeat.
We don't need IK, because we're not doing polygonal deformations- just simple move / rotate transforms.
People who don't understand BOS don't get why we want to keep its strengths... and lose the weaknesses.
Strengths of BOS:
1. Parameterized, randomized or scripted transforms. You can program small variations in motion-over-time, or give a slightly new seed to a rotation's arc, to end up with randomized results that would be more organic and realistic. This is fairly impractical at the moment, because of some of the critical weaknesses of BOS, but it's quite practical if we have a visual timeline editor and playback viewer.
However, parameterized and scripted transforms are a snap. Tie into a game variable, a timed state, or anything else you want to set as a condition, and you can make things happen in perfect order.
With a visual editor allowing us to quickly do the "rough cuts" of individual motions, I can see us doing some very, very powerful stuff with this. Everything from having soldiers walk with a noticable limp if they've been wounded to having a building fall apart in randomized ways as it takes damage. Don't base your assumptions on what is already out there- we've been limited by a primitive editing environment, and have only so much free time.
2. Perfect precision. Want to speed something up by 10%? You can go through a series of NOW/SLEEPs and cut down the SLEEP time 10%. Very hard to do with traditional IK-based animation techniques- if you're lucky the animation still hangs together somewhat correctly, but will require lots of tweaking. Which is why people working in IK settle on timeframes very quickly, and then stick with them, and why games whose content is based around IK animations (first-person shooters are a great example) take so much effort to develop. Want to have the guns of every character in Counter-Strike: Source shoot twice as quickly, with perfect visual fidelity? Good luck on that one- it's not as simple as cutting the timeline in half. BOS doesn't have this problem.
3. Non-linear outcomes without source code revision. Because all animations are scripted, we can have more than one outcome path for a given event, either through slight random factors, or through multiple animation sequences. The possibilities here are tremendous.
Weaknesses of BOS:
1. BOS cannot GET/SET many of the game variables in Spring yet. This limits its usefulness.
2. No scalar transforms for pieces. This is an engine limitation as well as a limitation of BOS.
3. Poor editing environment. BOS is currently editable with one tool- Scriptor. Yes, there are other tools available, but most of them don't work as well.
4. No playback environment, other than the game engine.
Get rid of the weaknesses, and BOS + a game engine that supports it is a very strong animation environment.
you understand me wrong :).
Lets think about a 3ds max scene with a 60 frame animation of a rotating ball that follow a path.
The plugin would ask you wich animated object you want to export, you select the ball and the script write a txt file with something like that:
//FRAME 1
turn ball to y-axis (2345) speed <3245>;
turn ball to x-axis (2345) speed <3245>;
turn ball to z-axis (2345) speed <3245>;
move ball to y-axis (2345) speed <3245>;
move ball to x-axis (2345) speed <3245>;
move ball to z-axis (2345) speed <3245>;
wait 324;
//FRAME 2
turn ball to y-axis (345) speed <325445>;
turn ball to x-axis (23) speed <325445>;
turn ball to z-axis (654) speed <324545>;
move ball to y-axis (34) speed <324545>;
move ball to x-axis (45) speed <3255>;
move ball to z-axis (34) speed <455>;
wait 324;
.
.
.
//FRAME60
.
.
then you copy and paste this in your script and compile and you got the same animation you have in 3d studio max
I made the same thing manually with excel and a bit o patience to make almost perfect leg animations for a mech.
Lets think about a 3ds max scene with a 60 frame animation of a rotating ball that follow a path.
The plugin would ask you wich animated object you want to export, you select the ball and the script write a txt file with something like that:
//FRAME 1
turn ball to y-axis (2345) speed <3245>;
turn ball to x-axis (2345) speed <3245>;
turn ball to z-axis (2345) speed <3245>;
move ball to y-axis (2345) speed <3245>;
move ball to x-axis (2345) speed <3245>;
move ball to z-axis (2345) speed <3245>;
wait 324;
//FRAME 2
turn ball to y-axis (345) speed <325445>;
turn ball to x-axis (23) speed <325445>;
turn ball to z-axis (654) speed <324545>;
move ball to y-axis (34) speed <324545>;
move ball to x-axis (45) speed <3255>;
move ball to z-axis (34) speed <455>;
wait 324;
.
.
.
//FRAME60
.
.
then you copy and paste this in your script and compile and you got the same animation you have in 3d studio max
I made the same thing manually with excel and a bit o patience to make almost perfect leg animations for a mech.