Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Dirst]

what i meant is pretty much what Putnam said.combat logs are filled with opponents biting improbable spots,parts sailing off to the horizon,and grappling moves that defy regular anatomy.it would be difficult...but since you have far more experience on the subject than me and you say it can be done at least to a degree,i take that back

I doubt it . Yeah, i admit combat needs to wait a few updates before it can properly handle something like this. I should ask in the stonesense thread why he used what he used.

Just so you know, Stonesense doesn't really animate creatures based on what they are doing.  Every sprite has six frames of animation which are cycled constantly.  Good for a bird flapping its wings, but not much else.

[Scoops Novel]

I'm looking at this, a dwarf appearance visualizer (in 2d at the mo), with interest, though it is on hold. http://www.bay12forums.com/smf/index.php?topic=141245.0. It makes me wonder, is the problem mostly animation, or the models, or both? Say if you we're "just" showing an adventurer walking through a village

[Dirst]

I'm looking at this, a dwarf appearance visualizer (in 2d at the mo), with interest, though it is on hold. http://www.bay12forums.com/smf/index.php?topic=141245.0. It makes me wonder, is the problem mostly animation, or the models, or both? Say if you we're "just" showing an adventurer walking through a village

Plucking a quote from the Stonesense thread:

Secondly, dfhack gives us a lot of information, but it doesn't give enough information to determine when a dwarf is performing an action. It can tell that the dwarf is given a job, but it can't determine when the dwarf is actually doing it.
So for example, you will never see your dwarves in the proper pose for slashing that goblin, or even moving smoothly from tile to tile.

Similarly, 3d programming isn't exactly easy either.

Making 3D models is a lot of work, and rigging them for animation is also a lot of work.  However, for humanoid and quadruped creatures there are people making and selling art assets that could be adapted for a DF animation tool.  And at some point in the future combat might be fixed to eliminate battle axe blows aimed at molars.  The problem would be the plethora of other creatures in DF because right now no tool exists to take a BODY definition, build a model out of suitable pieces, and animate it.

If you'd like to spend some time learning biomechanics and inverse kinematics, such a tool would be awesome not only for DF but to license out to game developers everywhere.  A mock-up could just use rectangular blocks for the bodyparts and still wow the socks off of everybody.

On the other hand, if your interests are more in the direction of programming, get to know the folks who dig around DF's internals.  DF itself knows what a creature is doing, and exposing that to DFHack and Dwarf Therapist would be immensely useful.  The initial use for such a thing could be to make much, much more detailed logs as an input to storytelling utilities and fort diagnostic tools and !!SCIENCE!! projects.  Eventually one of those storytelling utilities might be the after-animation tool you envisioned.

[Findulidas]

Not to mention that all body parts are essentially abstract notions of connections with other parts that have abstract tissue layers and the occasional abstract position compared to another abstract part.

Get real

[Dirst]

Not to mention that all body parts are essentially abstract notions of connections with other parts that have abstract tissue layers and the occasional abstract position compared to another abstract part.

Get real

I didn't say the layout tool would be easy.  Something that got 80% of the way toward handling a Creeping Eye would be impressive.

[Scoops Novel]

So, everything but spiders, forgotten beasts and a few others can be done relatively easily?

[Dirst]

So, everything but spiders, forgotten beasts and a few others can be done relatively easily?

Oh no, don't misunderstand.  Making humanoid and quadruped models is a pain in the ass.  However, these things are common enough in so many different applications that a market exists for them.  You can get bad ones for free, nicer ones for a price.  Over time, the overall quality of what's available should improve no matter how you spend your time.  Therefore, your time is better spent on a part of the project that isn't going to just happen on its own.  By the time you're gotten somewhere with your contribution, the humanoid/quadruped model situation will be better.

[Scoops Novel]

What about the scenery? I'm guessing that's within reach.

[Findulidas]

Not to mention that all body parts are essentially abstract notions of connections with other parts that have abstract tissue layers and the occasional abstract position compared to another abstract part.

Get real

I didn't say the layout tool would be easy.  Something that got 80% of the way toward handling a Creeping Eye would be impressive.

I know, it was a joke based on the fact that everything was abstract and that he said abstract so many times.

[Dirst]

What about the scenery? I'm guessing that's within reach.

There are a small handful of visualizers with various strengths and weaknesses.  Personally I prefer Stonesene, but it wouldn't do anything for your 3D spaces since it is an isometric view from four fixed viewpoints.

People have been making custom textures for 3D terrain since at least Doom (where there any for Wolf3D?), so that is quite achievable.  Read out everything DFHack knows about the map, place all of the walls and items, and render.  The chokepoints would be the art assets and figuring out how to wrest all of the map info from DFHack.

For a finished product it would require a large number of textures, and a large number of items (buckets, low boots, drawbridges, toy boats, etc.) but it wouldn't need everything to get started.  I just don't see it making the leap to including creatures without somebody undertaking a Herculean tasks of building a body-constructor and extracting highly detailed activity data from DF.

Of course, if you wanted to do any of those three things, others in the DF community would find ways to incorporate it into other projects.

[Veylon]

Not to mention that all body parts are essentially abstract notions of connections with other parts that have abstract tissue layers and the occasional abstract position compared to another abstract part.

In other words, there's little to no date in the game about where anything is or what it looks like. There's no data telling you that legs are down and heads are up in a humanoid.

What you could do that might work is give all the parts buoyancy and nail the [STANCE] parts to the ground so that it's like a helium-filled balloon animal with lead feet. Then cull the [INTERNAL] parts. That ought to produce something vaguely correct looking, although all humanoids will be holding their hands up. If that's an issue, then [GRASP] parts (that aren't also [STANCE] ones) could be nailed to a point halfway between the ground and whatever the average [HEAD] height is.

For non-vertical animals,

and

are defined, but there's not front or back. But I think it's fairly safe to say that [UPPERBODY] and [LOWERBODY] can substitute. Check which one parts attach to and that should determine whether they ought to pull fore or aft.

Sure, things will look super deformed, but they're technically drawable.

[Putnam]

So for example, you will never see your dwarves in the proper pose for slashing that goblin

I'm a bit late here, but I don't think that's right as of 0.40.01. Attacks are now something that can be in progress and you can even interrupt them by catching them with your hands in adventure mode.

Not to mention that all body parts are essentially abstract notions of connections with other parts that have abstract tissue layers and the occasional abstract position compared to another abstract part.

In other words, there's little to no date in the game about where anything is or what it looks like. There's no data telling you that legs are down and heads are up in a humanoid.

What you could do that might work is give all the parts buoyancy and nail the [STANCE] parts to the ground so that it's like a helium-filled balloon animal with lead feet. Then cull the [INTERNAL] parts. That ought to produce something vaguely correct looking, although all humanoids will be holding their hands up. If that's an issue, then [GRASP] parts (that aren't also [STANCE] ones) could be nailed to a point halfway between the ground and whatever the average [HEAD] height is.

For non-vertical animals, [\LEFT] and [\RIGHT] are defined, but there's not front or back. But I think it's fairly safe to say that [UPPERBODY] and [LOWERBODY] can substitute. Check which one parts attach to and that should determine whether they ought to pull fore or aft.

Sure, things will look super deformed, but they're technically drawable.

That would probably look sillier than Armok 1...

[Dirst]

So for example, you will never see your dwarves in the proper pose for slashing that goblin

I'm a bit late here, but I don't think that's right as of 0.40.01. Attacks are now something that can be in progress and you can even interrupt them by catching them with your hands in adventure mode.

Not to mention that all body parts are essentially abstract notions of connections with other parts that have abstract tissue layers and the occasional abstract position compared to another abstract part.

In other words, there's little to no date in the game about where anything is or what it looks like. There's no data telling you that legs are down and heads are up in a humanoid.

What you could do that might work is give all the parts buoyancy and nail the [STANCE] parts to the ground so that it's like a helium-filled balloon animal with lead feet. Then cull the [INTERNAL] parts. That ought to produce something vaguely correct looking, although all humanoids will be holding their hands up. If that's an issue, then [GRASP] parts (that aren't also [STANCE] ones) could be nailed to a point halfway between the ground and whatever the average [HEAD] height is.

For non-vertical animals, [\LEFT] and [\RIGHT] are defined, but there's not front or back. But I think it's fairly safe to say that [UPPERBODY] and [LOWERBODY] can substitute. Check which one parts attach to and that should determine whether they ought to pull fore or aft.

Sure, things will look super deformed, but they're technically drawable.

That would probably look sillier than Armok 1...

I think some "telemetry" for each of the bodyplans would be a reasonable amount of work, and it would be held off to the side in the app's own data like Stonesense sprites are separate from the core game's graphics.  Most modded creatures re-use the existing bodyplans, so this extends nicely beyond vanilla (though the results might not look like what the modder imagined).  Particularly persnickety modders could add telemetry to their own bodyplans in the same format, and custom bodyparts if they don't like how they get rendered from stock parts.

The word "telemetry" is in quotes because I'm not sure what the technical term is in 3D art.  It would tell the app where to attempt to attach each bodypart, for example the telemetry for 4ARMS_STANCE would direct the engine to attach RUA1 to the front-right of its CONTYPE (which happens to be UPPERBODY) and RUA2 to the rear-right and so on.  The telemetry data might also include some generic animation scripts like MOVE_FORWARD_(gait) and FALL_TO_LEFT.

The really heavy lifting will be in the 3D art assets.  Even with textures to handle material differences, the visualizer will need a pretty hefty number of bodyparts to look mildly realistic.  Fortunately, the telemetry work can proceed with incredibly simple artwork like rectangular blocks.