Video Tutorial: Using 3DS and UpSpring

[smoth]

this is where you and I draw the differences though argh. I care about quality and the extra time of doing it correctly is worth it to me.

[Argh]

That's where I'm at on this as well, pretty much. I could give a hoot, if I edit it in a Lua application or UpSpring or whatever, so long as it doesn't have some cruddy, non-standard approach to UI.

Doing it in the engine would be bigger pain than just fixing UpSpring's flaws, imo, because it already implements four-view, etc.

It won't be suitable for MD3 / MD5, but meh... there's the one situation where I'd be OK with having to hand-edit a text file, because it'd merely be attachment points and emitters, not rotational setups for animation.

Totally different situation than having to, say, /reload luarules over and over and over again to get a model's joints right, which is trivial in UpSpring. For all of its flaws, after JC wrote Euler Angles, it gets that part right.

[SpliFF]

On the other hand Spring can show you ACTUAL scale and ACTUAL texture/normals and let you see your objects relative to the footprint and other units. In addition it runs on every platform that runs Spring and by definition it always will. It would also support every model format Spring does. I wouldn't be so quick to dismiss the concept if "workflow" was my aim.

I get your concerns, really, but you're trying to compare something that exists with something that doesn't as though they're in any way comparable. I've seen editors implemented inside game engines before. Is that what Worldbuilder is?

[Argh]

You can compile UpSpring on Linux, IIRC.

[Satirik]

why do all american have duck voices ?

[smoth]

this is where you and I draw the differences though argh. I care about quality and the extra time of doing it correctly is worth it to me.

[Argh]

I have a nasal Midwestern nerd-accent and it's winter and it's a cheap microphone. Sorry.

@SpliFF: World Builder's a level editor... kinda different situation. The UI was simplicity itself, because it's using things that were already there for the most part.

You're talking about implementing something like VaLVe's rigging suite inside Spring. The UI you'd have to build would be a much bigger workload.

Anyhow, that's your problem, but I'd still be more inclined to rip out all of the junk from UpSpring, fix the major bugs and just make it do the new things you want, if I were in your shoes.

I figure that most of it's the same problems either way- things like rescaling are going to require destructive changes to meshes (i.e., one-way ticket), you can't just use OpenGL to scale stuff and offset it, it will cause more problems than it solves (at least in my experience messing with that).

Maybe spend some time with the tool you're given to disparage, then read the source to understand what went wrong, before talking about the brave new world you want to build?


@Smoth: I already addressed your points and explained how you could do it significantly faster without any quality difference at all. If you can't deal with a different workflow, tough, but that pretty much finished that discussion so far as I'm concerned.

[smoth]

you are never wrong....


Fact of the matter is that it is a different workflow yeah... and you know what I find it more tedious because I already tried it.

As always, I am not going to stand idle by while you dole out ill advice to new modelers. They need to know that there are issues and while I understand that you don't run into them, others will. your way is not the best, there is no best way and frankly you are sacrificing quality by relying on the recal norms. i used to use it to, I do not use it any more and no I wasn't doin' it rong.

[SpliFF]

Totally different situation than having to, say, /reload luarules over and over and over again to get a model's joints right, which is trivial in UpSpring. For all of its flaws, after JC wrote Euler Angles, it gets that part right.

That's something else I meant to ask about. What's the deal with "rotational offsets" etc. Isn't that the job of your modelling software or is the issue that there is no way to define "forward" for a piece in other formats like MD3? I find that a little hard difficult to believe since other game formats support animations. Am I missing something here?

Are you perhaps talking about the point around which the whole model turns? If so can this not be set in wings by positioning the model relative to the origin, or is it a per-piece thing?

Basically I'm trying to determine why it is that Spring has these issues but other software like Quake does not.

My only issue with UpSpring, if you ignore the bugs, is that it's even necessary. Which comes back to the question of why, now that Spring can potentially support all major gaming formats, are we not able to use the same tools and apply the same techniques without using 2 different tools?

[Argh]

Spring has these issues because of the way COB / Lua work. Rotational offsets are necessary, because each Piece needs a discrete center to rotate around; otherwise we'd have to perform a transform relative to the center, which is basically what the software does for us, but because we've given it the offset, it's easier for both the engine and the animators to deal with.

In formats like MD3 / MD5, all of that's internal to the animations themselves, IIRC. You don't actually do bone rotations (i.e., "real IK") in the game- you're just calling / interpolating static animation states, to create the illusion of motion. It's a very different way to do animations, basically, and it's one of the many reasons why MD3 / MD5 support is at the top of my want-list.

@Smoth: Don't knock something you obviously haven't even tried yet.

[smoth]

and you know what I find it more tedious because I already tried it.

[Argh]

<shrugs> just putting that out there; when you've re-read the instructions, give it a whirl, it was really easy and it's a lot faster than edge-loops and you'd save a lot of time.

[smoth]

EXTRACT REGION NORMAL WILL RESULT IN THE PIECE CHANGING SIZE!

[Argh]

Not if you hit tab and select 0.

[Pxtl]

Can't you guys just agree to disagree? You obviously have different priorities - Argh's looking to put models out in a matter of hours - an impressive feat - , and Smoth is making meticulously-sculpted recreations of something he loves. Obviously you're going to have different workflow.

edit: I still think that the best way to get MD3-support would be to bolt it onto the existing format - the ability to load a vertex-animated piece instead of a static piece, otherwise behaving the same as a standard model. A q3 MD3 becomes a set of keyframed parts. The only real miss would be single-texture limit.

[smoth]

LOL, I know. I keep saying that Pxtl... but I don't want him telling noobs that this method is good for quality.

[Argh]

No. And the reason for that is simple: I will not tolerate the whole, "don't tell newbies this" bullshit from people like Smoth.

That's unacceptable, when I'm providing free, useful information. If he wants to teach another workflow... then he should teach it, instead of turning every attempt I make to release some of my knowledge into a fucking flame-fest.

Anyhow, I'm going to request a thread lock on this, because I don't have time to put up with this bullshit.

[SpliFF]

In formats like MD3 / MD5, all of that's internal to the animations themselves, IIRC. You don't actually do bone rotations (i.e., "real IK") in the game- you're just calling / interpolating static animation states, to create the illusion of motion.

Sorry Argh, I just don't buy that as an explanation for why UpSpring is required. I'm going to do my own research.

One thing about assimp that you don't seem to realise (though I've mentioned it several times now in other threads you responded to) is that it provides you with the models bones and also the nodes (pieces) rotated relative to their parents. That means practically all modern formats it supports (MD3, MD5 and Collada at least) must carry this data and if they carry the data there's a way to CREATE and STORE the data that doesn't require UpSpring.

Obviously Spring doesn't know how to use that data yet but it shouldn't be a major hurdle for me to teach it.

This conversation will just keep going in circles because you don't really seem to understand all the technologies involved, only your experience with Spring.

I don't want an argument, I want facts.

[smoth]

people like Smoth.

how do you mean people LIKE me?

If he wants to teach another workflow... then he should teach it, instead of turning every attempt I make to release some of my knowledge into a fucking flame-fest.

Because you state things inaccurately and I am trying to point out some things that will cause issues. Saying that I should go and produce some work flow tutorial is only bait so you can turn it into some kind of contest and try and pick apart anything I do. I am not stupid enough to fall for that.

When I debate the "knowledge" you lay out I do so because you are telling people things and either omitting details or outright wrong. Just like when you argued that pink was red and when you argued that teamcolor is an additive blend. It isn't about flaming it is about making sure the noobs have the right information at hand.

using extract 0 does not allow you to access the old geometry without moving the new geometry. I am aware of the tab button(it was in my walk through) and having done what you are suggesting. I suggested using a Y extract because it will allow you to dispose of the geometry via deletion or hole material. I should have said hole material but even so, using extract normal versus Y shows to me that you are not really looking at it thoroughly. All the while dismissing my point because you say I did not look at it.

I did and have used that method in the past.(specifically the rx78) I went back and redid all the pieces in wings because I was unsatisfied with the issues that the recalc normals thing create. it is not always good and many times I have found it is very picky with regards to what model geometry it wants to respect. Rather than fight the system and warp my mesh to meets it's needs I use a workflow that I find outputs acceptable quality.

Your method is fast, same for your texturing and other things. However, fast is not always better and I am trying to make SURE that people know there are other ways of doing things.

[SpliFF]

http://en.wikipedia.org/wiki/MD3_%28file_format%29

Tag

An attachment point for another MD3 model.
Data Type Name Description
U8 * 64 NAME Name of Tag object. ASCII character string, NUL-terminated (C-style).
VEC3 ORIGIN Coordinates of Tag object.
VEC3 * 3 AXIS 3x3 rotation matrix associated with the Tag.