Print

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

[Ciehoo]

I too struggle to see a solid implementation of this. I mean, doing the walls and buildings and trees and such is all well and good...
But for 3D real time I'm assuming you're going to want to animate things. Even now Dwarves would have a ridiculous amount of animations, some of them implausible, like stacking dwarves on a single tile, or combat. Because DF doesn't animate attacks, it doesn't need to consider what's "possible" and doesn't have to consider the needs of any graphical representation. It's all abstracted. You can't keyframe that sort of thing.

Of course, you don't have to do that. You could probably do a few basic animations, but I think what people are picturing, and what's most likely possible, are two very different things.

I figured static characters.  I fully don't expect fully animated characters with real model based hit-testing and all that crap.  I think most people that think 3D DF is not feasible think that it should look like a modern RTS with fully animated creatures.  I think a "chess like" interface would be fine at first using strictly static avatars.  (old-school chess, not Battle Chess)

To answer both points. I don't think doing it with fully animated models would be that hard, it would only require 1 more graphics step (creating and animating a skeleton - which could, in theory, be shared by all humanoids). The FPS hit could be an issue, but modern RTS's manage to do many more models on screen than in DF.

And as for implausible and numerous animations. With skeleton based animations, you could separate the creation of models and animations into two distinct branches. With each humanoid model being able to use each animation on the humanoid skeleton, the combinations happen by themselves. And they can be implemented gradually, replacing, i.e. MessageLog entries, hovering above appropriate characters' heads.

This could even allow for some form of crippling, as well as individual items. It all boils down to the ammount of work the graphics people would be willing to put in.

Graphics wise, on a scale from 1 to 10, with 10 being a AAA title, this mod could be at least a 5.

Ciehoo

[Sean Mirrsen]

Doing character models is going to be RIDICULOUS. Completely. Unless Toady does something to the raws akin to the hit charts I proposed, you're going to end up with ridiculous monstrosities. Sprites are better. For something like this, a system from IVAN would work best. And then there's the problem with displaying multiple items in the same cell, which can't be handled in any way except with sprites.

The sprites wouldn't show the equipment, but unlike everything else it's not completely impossible to create separate sprites for, say, sleeping, attacking, being prone, swimming, etc. If anything is lacking it would use a default sprite. All the status can be shown with a neat little 'display' square under the creature's feet - stuff like bleeding, hunger, thirst and all could be just tacked onto the sprite without any problem whatsoever. Even hauled items.

I don't know Ogre or asm, but I'm fairly sure I can read and process C++, so if you could put the code up somewhere I might look into these issues.

[Ciehoo]

Doing character models is going to be RIDICULOUS.

Sorry, you're wrong. Making one character model would take the same ammount of work as making a good quality sprite, that would work well in a 3d environment. Adding each animation/state to a sprite based system would take the same amount of time as the first one. With skeleton based models, each animation would take 10-15 minutes to look good, and you can use the same animation for every hummanoid in the game.

Let's do the math:
10 hummanoid models
10 states
== 100 sprites to draw.
or
10 character models
10 skeleton animations
== 20 "work units"

Sprites are good if you need variety, and don't require animations. When you do, it becomes an excersise in futility to manage the endless combinations.

With 3d models you only need to do everything once. 1 model per character, 1 animation per state (walking, sleeping, fighting etc.), even 1 model per carried/worn item. By the wonders of skeleton based animation, everything can be combined to form the final visual representation of a character doing something, while wearing some things. With sprites, you'd have to draw each and every combination by hand, increasing not only the workload, but also memory requirements.

Rember, 1 character model in memory + texture + skeletal animation equals roughly 3 sprites at decent resolution. But while adding variety to 3d models gives a linear progression of memory use, the same progression raised to the power of "degrees of combination" for sprites.

I'm not saying sprites are out of the question, but I'd think they would only be useful as placeholders in the beginning. As the content would get added, the benefits would quickly be outweighted by the problems described above.

Ciehoo

[Sean Mirrsen]

You won't be able to handle many objects in one tile with 3D models, and you will still need sprites for status. 3D models tend to clip into each other, producing a royal mess instead of a nice picture.

Plus you need to account for mods.

On the overall, I might not be completely against it, but the option of just using sprites and existing graphics packs should be there.

[Sergius]

Seriously, it seems a lot of people think 3D graphics and models is like some kind of myth, something impossible to achieve and that somehow all these years mainstream game developers have been perpetuating some kind of hoax on us...

Believe me, o people of Bay 12 Games. I have seen 3D graphics, they are real and they live amongst us. There are meshes and vertexes hidden amongst every one of our computers, waiting until the time is right to take over. They are here to kick ass and chew bubblegum.

[Sean Mirrsen]

If Crysis put as much raw CPU power into gameplay logic as it does into tessellation, it would be a much better game.

3D graphics are all fine and good until you realise that the seven and a half hundred cats that populate your fortress are forcing your CPU into meltdown.

[Randominality]

You won't be able to handle many objects in one tile with 3D models, and you will still need sprites for status.

I think that there isnt a problem with this, you simply use the way multiple things on 1 tile are displayed in DF atm. Just switch between them 1 at a time so if a dwarf and a human were on the same tile it would alternate the two models one after the other. That should solve the clipping issues and would look neat too.

[Ciehoo]

You won't be able to handle many objects in one tile with 3D models, and you will still need sprites for status. 3D models tend to clip into each other, producing a royal mess instead of a nice picture.

I don't think that's going to be that much of a mess. You could subdivide the cells into 4 "subcells", and add some collision avoidance for same size humanoids. There's a plethora of ways to avoid that, and even if the ultimate solution isn't perfect, it's still better than hiding all but one entity in a cell to avoid z-fighting between sprites.

Plus you need to account for mods.

Actually, not really, I don't. If I release it as open source, then yeah, you can add them yourself. If someone takes over, and would want to go this route, I'd object, but it would be out of my hands. But If I'm going to continue working on it, then it won't happen

3D graphics are all fine and good until you realise that the seven and a half hundred cats that populate your fortress are forcing your CPU into meltdown.

If you would have all the cats visible on screen, at once, then... nope. Please don't assume other people are unable to solve problems like that, because many, many bright minds (not mine, mind you) dealt with  this problem, somewhere around, I dunno, Rome:Total War for example (and this was in 2004).

[Sean Mirrsen]

It would NOT look neat. While you have plausible deniability with ASCII graphics, as in you can understand there's only so much you can get out of it and use the additional information provided to assemble the full picture. With 3D graphics, switching between the models that are in one place would be ridiculous, and completely out of place. The best you can do is have the sprites of the creatures present arrayed in the cell like spots on a die. Same goes for items. Models placed this way would be intersecting, unless you go the Total Annihilation route, which is pretty much overkill in this situation, but provides the best of both worlds.

Btw - Rome:Total War and any other game like that has a)LODs and b)a grand total of "a few" unique types of units on a battlefield at any given time, with no or very little visual difference between individual units.

And if you don't account for mods, then.. I don't know why bother with this. I haven't played vanilla DF in hell knows how long. I know that many use the vanilla game, but most that do use it exactly because they don't want it modified in any way. If you don't account for mods, it's basically worthless - I can live without a 3D view, but not without custom races and creatures. And then there's the fact you have to rewrite it every time a new version brings creature changes. I mean, rewrite it more than you usually would.

[Sean Mirrsen]

Sorry for doubleposting, but does it even work for anything but the specific site it starts on? (and that's not taking the fact it's mangled to hell and back) Embarking on any other site doesn't work.

[Ciehoo]

Btw - Rome:Total War and any other game like that has a)LODs and b)a grand total of "a few" unique types of units on a battlefield at any given time, with no or very little visual difference between individual units.

Sigh, please, let it be. Just accept that I know what I'm talking about, and I know when the rendering pipeline would be GPU,CPU or memory bound.

Besides, am I right in assuming you're talking about using the sprites made for DF to denote objects in game? Or am I  way off base here?

And if you don't account for mods, then.. I don't know why bother with this. I haven't played vanilla DF in hell knows how long. I know that many use the vanilla game, but most that do use it exactly because they don't want it modified in any way. If you don't account for mods, it's basically worthless - I can live without a 3D view, but not without custom races and creatures. And then there's the fact you have to rewrite it every time a new version brings creature changes. I mean, rewrite it more than you usually would.

Well, you see no point to this, but others might. I'm not forcing it down anyone's throat.

[Sean Mirrsen]

Yes, you're right in that I propose to use the graphics normally present in form of graphic sets for DF. And animations are not required.

But the question still stands, have you at least tested this creation of yours? I can't get it to work anywhere other than the one starting location your savefile comes with.

[Ciehoo]

Yes, you're right in that I propose to use the graphics normally present in form of graphic sets for DF. And animations are not required.

Then you know how a 16x16 pixel texture would look when zoomed in?

But the question still stands, have you at least tested this creation of yours? I can't get it to work anywhere other than the one starting location your savefile comes with.

As I said in the first post - this wasn't extensivelly tested and polished - the only thing I did on it in the last 6 months was to update it to the current version. That's why I posted the request for someone to take over.

Case in point, if you're not interested, please do not troll here.

[Sean Mirrsen]

On the contrary, I am. I've been participating in an opensource project once. If it indeed has potential (at least it looks like it does), it would be a shame to just let it slide somewhere. But really, throwing it onto sourceforge or anywhere else will do the project much more good than just choosing a successor.

[Footkerchief]

Then you know how a 16x16 pixel texture would look when zoomed in?

They look awesome.  I'm serious.  Don't have time for anything more than this hit-and-run post now, but I'll be back.