UpSpring Replacement Wishlist - Page 2

UpSpring Replacement Wishlist

Share and discuss visual creations and creation practices like texturing, modelling and musing on the meaning of life.

Moderators: MR.D, Moderators

User avatar
maackey
Posts: 490
Joined: 02 Jul 2008, 07:11

Re: UpSpring Replacement Wishlist

Post by maackey »

thesleepless wrote:but currently it works and you can download it and use it.
I can't get it to work :cry:
User avatar
jcnossen
Former Engine Dev
Posts: 2440
Joined: 05 Jun 2005, 19:13

Re: UpSpring Replacement Wishlist

Post by jcnossen »

I have just started porting upspring to C#, so the code should get a lot more accessible then (At least IMO). It should also be a lot easier to port to linux, using MonoDevelop

See http://github.com/jcnossen/upspring.net

Is there anyone who wants to help once I got the basics running?
I only really want to make a subset of the upspring functionality (basic model manipulation and S3O import/export, maybe 3DO), and could use some help writing file importers or other stuff...
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: UpSpring Replacement Wishlist

Post by smoth »

C# ha ha fuck yes! I am interested in this.
User avatar
thesleepless
Posts: 417
Joined: 24 Oct 2007, 04:49

Re: UpSpring Replacement Wishlist

Post by thesleepless »

maackey wrote:
thesleepless wrote:but currently it works and you can download it and use it.
I can't get it to work :cry:
can you detail what happens on the importer / exporter thread and i'll try and fix it?
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: UpSpring Replacement Wishlist

Post by FLOZi »

Wish it were Java :cry:
User avatar
MidKnight
Posts: 2652
Joined: 10 Sep 2008, 03:11

Re: UpSpring Replacement Wishlist

Post by MidKnight »

FLOZi wrote:Wish it were Java :cry:
Wish it were Python. :cry: :cry:
User avatar
thesleepless
Posts: 417
Joined: 24 Oct 2007, 04:49

Re: UpSpring Replacement Wishlist

Post by thesleepless »

MidKnight wrote:
FLOZi wrote:Wish it were Java :cry:
Wish it were Python. :cry: :cry:
+1

the blender plugin is python =)
User avatar
MidKnight
Posts: 2652
Joined: 10 Sep 2008, 03:11

Re: UpSpring Replacement Wishlist

Post by MidKnight »

Many prominent Spring coders know how to use Python.
Python is easy to read, debug, expand, and maintain, it has a lot of neat high-level features.
Also, people who know other languages, especially high level languages like Java, shouldn't have much trouble learning Python.
Python also sports some nice GUI toolkits, like WxPy and PyQt, both of which are cross-platform and look nice and native in each OS.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: UpSpring Replacement Wishlist

Post by FLOZi »

Well I would prefer Python to C# too (Infact I am particularly partial to python as it was the language I was taught to program with), but most windows users won't have it installed; java is fairly ubiquitous - across any platform.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: UpSpring Replacement Wishlist

Post by smoth »

Why would you want to develop something like upspring in python.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: UpSpring Replacement Wishlist

Post by Argh »

Is there anyone who wants to help once I got the basics running?
I still suck at heavy 3D, and I will be lost in C#, but I am certainly willing to do what I can.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: UpSpring Replacement Wishlist

Post by smoth »

c# is like the bastard child of vb and java... with some c++ influence... it is really easy argh.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: UpSpring Replacement Wishlist

Post by Argh »

Just saying that if there's something helpful that can be done, I'd be up for it- I am aware that UpSpring's kind of a black box to people, even though I find it really easy to use. I can't imagine what I could contribute that would be all that useful, beyond specifications, but what the hell.

An idea: perhaps the parsing and drawing code should be modularized, so that maybe AF can write a front-end for browsing models and animations? IOW, build it so that UI can call it as a DLL / SO, and build more than one application around it, maybe merged in a workflow? I am almost tempted to stop working on Glest stuff long enough to do some UI pondering, but meh, I said I was going to finish it, so I'd better keep going.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: UpSpring Replacement Wishlist

Post by AF »

I can do my own UI pondering thank you =p, go work on glest stuff, I wouldn't expect anything from me in the next 3 or 4 months, and there's the blender plugin effort after all
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: UpSpring Replacement Wishlist

Post by Argh »

You don't want to work with JC on a joint thing? Seems like that's putting two strengths together in a useful way to me.

I am seriously surprised that he was even interested, and you could probably learn a lot from JC that can applied elsewhere, AF. Further projects and down the road, and all that.

Anyhow, suit yourself, I was just saying that it makes sense, given what you've been talking about in terms of UI framework stuff. I don't mean to cause any huffing or puffing by playing favorites, I figured that this was something where you guys both have strengths that might result in a better final product.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Re: UpSpring Replacement Wishlist

Post by Argh »

Here... meh, I am going back to Glest stuff after this... I'll use words, pictures take too long:

Workflow should be something like this (again, imagining this tabbed)

Asset Import and Initial Setup.

You bring in new assets (meshes, textures, define a shader and a baseplate / waterplate / cubemap, if you're going to use that stuff, should have defaults ofc).

You should also define the hitsphere / cuboid / column here.

You should scale all Pieces or the whole model here. Scaling needs some tools that UpSpring didn't have- scale markers, for example, and different grid sizes (I literally have had to import scale figure meshes into my World Builder models to get scales approximately right).

At the end of this process, you should see your model in the imported pose, with the shaders, etc., and if you need to stop right there and fix things, you can do so. If you want to tweak the shader, you should be able to do that and reload it.

On shaders: if somebody is brave enough to give it a go, I'd say a max of five textures is enough for most things. I'd also like a delta-time or a delta-frame, for time / frame-based shaders that use procedural animation.

Needless to say, if people are foolhardy enough to want to try this stuff, they need to know wtf they're doing, and they may have to alter the GLSL a bit when porting into Spring, but it might get a lot more people interested in this subject, if they had an environment they could work with, then drop into a standardized piece of structural Lua with minimal modifications. Needless to say, there should be as many stock shaders as people feel like providing.

Rigging and practical setup.

You should do your moving, rotations, scale, mirroring and import of things like named point groups, etc. here.

Generally speaking, you won't need to do much of this, but you'll want to set up Piece origins at the very least, and the other things are occasionally a lifesaver to have here in the post-import workflow. I've lost count of how many times UpSpring's ability to do these things "in-house" has saved me from having to export, rework in the modeling environment, etc., so I would certainly want all that here. I would love a grid-snap, so that I can drag the centroid points a 10/th elmo, for example, for nice clean numbers in the final scripts, etc.

Lastly... and this is really only important if we want to include animation output as part of the specification, you should be able to set up constraints on the motion of Pieces, that have no effect in Spring, but should be saved (how that could be done without altering S3O specification, don't ask). That would make the next part super-intuitive.

Animation.

In theory, we'd hit a button to declare an animation. It'd give us a drop-down of common stuff, and be smart enough to know that we're defining, say, the AimWeapon for weapon3, because we've already defined 1 and 2. Or we could hit "other".

With constraints... in theory, we could just "grab" Pieces with the mouse, and push-pull them to the right spots- if you grab a foot, then it will also pull the knee and thigh. Talk about instant improvement for artist productivity- I've done this in IK systems, and while it takes a bit longer to set up, after that it's intuitive and easy. It should allow Pieces to be "locked", as well as auto-locking the base, so that only Pieces higher in the hierarchy can be moved, so that moving a toe won't screw up an entire walk-cycle pose.

Voila, a keyframe. Now move time to the next increment. Keyframe. Hit playback, watch it run. Hit it with loop on, watch it loop.

Go and adjust things at a midpoint, and it would automatically write the script again from the start, to ensure that the resulting script is totally clean. We should be able to add loops with a button, where it asks for the variable name, and then puts the appropriate "while-->end" around it in the script.

Hide Pieces with a button at the keyframe. Play-sound, ditto, enter name (this assumes that people are using the new sound support). Lua callouts--> non-nub territory, just give a blank line and cursor, has to be the same with CEG, due to the non-trivial way that those need to be defined in the unitDef.

When done with a given set, hit some button to finalize it, and it should appear to one side as a named animation. You should be able to copy it (for example, do a walk()/walklegs()). I don't think merging's practical.

For some things, the looped approach (turn x to y speed z, sleep A, etc.) won't work. There should be a special mode for this, where we write it manually (random stuff, aiming code, etc.). I can't imagine how we'd make stuff like aiming / complex dynamic sequences nub-friendly, other than showing people examples. However, I can't think of a better way to show animators how to get into programming their animations than literally showing them how the instructions and math will work. We probably lose a lot of people, the minute they figure out (after days of trying to understand Spring) that our art workflow consists of mainly... seeing animations in our head, and doing math :P I know that most of the hardcore here, including me, think this is "fairly easy" or even "trivial", but it's not, and there's a reason most of the 3DOs ever made used rips of other people's scripts.

Animation playback and script editing.

First, it would prompt us for static-var (or Lua equivalent) stuff. It's a necessary evil, there's no getting away from how BOS or the Lua equivalent works- Spring is, and probably always will be, a primarily algorithmic approach to animation. As much as I'm trying to design this with the nub's needs in mind, there's simply no way to get past that totally. I have a feeling that if the previous stage is actually implemented, then people who can hack it up to that point will find coders to finish their work, if they can't cross the final bridge. Even if we have MD5, there's a lot that would need to be done here.

If the tool could export the entire state of the tool up to this point, so that the coder-types could see exactly what the artist saw and was wanting, then it would be pretty damn good for team productivity, though. Artist / coder teams could really give each other strengths impossible right now. The more I think about it, the more important I think that aspect might be. Sending people code fragments is not enough.

Now that we know our loops and static-vars, it should be practical to run animations, including loop / state-dependent stuff.

Ideally, we'd have buttons over on the side, one for each defined sequence. Hitting a button would either start a sequence, if left "bare"- no loops with states, or would ask for the states. In theory, a nub could program an entire animation this way, without knowing much about coding other than the concept of setting static-vars or masks, which is pretty easy to explain. Especially if common functions were made available in some sort of text file, so that people who were good animation coders could provide some things, like basic transport scripts, etc.

That said, it won't be perfect that way, there's no way to make it perfect without absurd levels of automation... and mainly it should be seen as a way to do playback on "bare" sections that you'd stitch together. This would still be a massive improvement over the current workflow, imo. And, if you open up the scripts at that point, you should be able to put in

Stuff like AimWeapon should be given random heading / pitch, and run through the whole system of operation. If the playback room still used the constraints, you could even see how your turrets would behave with arcs defined (ooh, being able to do that process visually would rock).

It'd be really interesting if heightfields could be brought in, btw- then even testing stuff where it's dependent on trig stuff would be possible. But that's a final sort've wrinkle, like actual playback of media, etc.



Anyhow, this is as much rumination time as I can spare for a few days, but I think this might be a good place for discussion, even if it's not feasible to develop this entire set of specifications in terms of UI workflow (or other folks have even better ideas).

But... AF, if you're going to go work on a separate project, this is basically what I'm looking for, plus / minus anything I've overlooked / not bothered with because I thought it was obvious, etc..

What we need is serious, no-nonsense, doesn't get-in-my-way tool that's designed for the fastest workflow possible and a collaborative workflow that's intended to bring artists and coders into closer harmony, better productivity, and clearer communication through visuals. When I think about how much better people could work, with the kinds of speedups I'm talking about from just building animations this way and sharing the projects with others, and the freedom that having more intuitive animation tools would give us... it's pretty exciting, frankly.

The way I envision the UI, you'd literally page through it, and if you were an expert, you'd have an animated, project-ready art asset in an hour or two, plus additional fiddling at the coder level (to put that into perspective, I rarely take more than 2 hours from starting UpSpring to finishing BOS coding atm, and usually more like 1, except for the most complicated logic stuff).

Ideally, if you wanted to go back and tweak further, you'd just return to the project's save-state (again, dunno how that's going to be dealt with, probably a separate filetype specification) and add stuff. I don't honestly think it can be made "smart" enough to do all the final linking and loop definition logic, etc., but if I want to add another death sequence, a walk-cycle variation, etc., then ideally I'd just go right back into the project, mess about building that new animation, export the raw script, and integrate with the current project. Much, much, much faster and cleaner than the current process, which really only makes sense to a few people around here, and has to be scary as hell to newbies.
User avatar
Guessmyname
Posts: 3301
Joined: 28 Apr 2005, 21:07

Re: UpSpring Replacement Wishlist

Post by Guessmyname »

Uh, by the way, shouldn't this be in the Engine Development forum?
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Re: UpSpring Replacement Wishlist

Post by AF »

  • I am not fond of C# UI programming one bit, my meddlings in C# with toolkit have demonstrated that there are numerous scenarios that are easily fixed but should just never happen, and never do happen in all the other UI kits I've dealt with.
  • C# Upspring would be spring only
  • I am not convinced by mono
  • I already have my own code base, one which is shared across many projects. Even if I abandon this idea, it would still be of use to me. Focusing on the one code base is a far better use of my time than focusing on 2.
  • There are other C# coders in these forums.
As far as what I have to learn from jelmer, I don't see shooting myself in the foot resource wise would be justification for it.
User avatar
jcnossen
Former Engine Dev
Posts: 2440
Joined: 05 Jun 2005, 19:13

Re: UpSpring Replacement Wishlist

Post by jcnossen »

About the language, this is really a port, not a rewrite. It will take maybe 5% of the coding time that upspring itself took. The geometry code is ported, and mainly the UI code is rewritten.
In C# I can use my existing stash of code, and porting C++ to C# is also pretty easy.
In any other language, it would take far too much time and I wouldn't even bother with it.

And another great thing, with .NET you get to use the whole range of languages to write plugins, VB, Boo, IronPython.. maybe that's a possibility for the python fans...
User avatar
Neddie
Community Lead
Posts: 9406
Joined: 10 Apr 2006, 05:05

Re: UpSpring Replacement Wishlist

Post by Neddie »

It is sweet enough that you're porting it in the first place.
Post Reply

Return to “Art & Modelling”