Welcome, Guest. Please login or register.

Pages: [1] 2
Print
Author Topic: Discussion - Production choices...  (Read 9655 times)
Sirren
Community member

Posts: 365


View Profile Email
« on: February 22, 2009, 12:14:43 PM »

Hello everybody.
I'm officialy in the graphical team and I'll start working as soon as the early planning stage is over.
I'm currently busy with fallout BG&E total conversions. I applied here as a character modeller/animator.
I'll probably only deal with critters... Save for the unforseen along the road, that is.
If I got it correctly some of you folks come from another project and have an already established pipeline... Using Blender, right?
I have a few questions which may be fit or not at this present stage, anyway:

A): Do we already have a standard T-Pose for characters?

B): Are we going to use a single rig/skeleton -for all human/non-human critters, for example.
Or different skeletons for three phisical types
Or male and female rigs
Or three rigs for male and three for female?...

C): Do you already agreed upon critters animations range? I mean, are we going to have Hit_Back/Hit_Front and so on Fallout style?
Standing stance only?
As far as Stand_Idle is concerned: Random animation à la Fallout or continuous à la Diablo?
Are we going to hide the character weapon in the Run animation?
Any established code to identify animations?
Err... Eight orientations for critters, right?
Maximum frames number for animations? Fixed or editable framerate?

D): How are we going to handle rendered sprites?
Preferred format (bmp, png...)?
Will the engine do something like read .PNGs according to a code, or are we going to pack them in some way (.FRMs style)?
Is movement going to be handled by sprites à la Fallout, or is the engine going to actually move our sprites?

E): Any sprite editor? I don't think we're going to develop a dedicated tool, right?

Anyway, this is what I managed to think of up to now. I'm sure there's more...
See you and have a nice Sunday.
« Last Edit: November 11, 2009, 09:58:07 PM by Gaspard » Logged
Lamoot
Community member

Posts: 161


View Profile
« Reply #1 on: February 22, 2009, 03:47:26 PM »

Ah hello, welcome to the team. With your addition there are already two of us on the graphical team Smiley You are that XSI artist that was interested in modeling organic stuff, especially characters?

Anyway, you seem to have a good idea what is required for such a project and ask some important questions.  Unfortunately I can't answer them all right now, since the answer depends on certain other prerequisites and some questions simply haven't been discussed yet. I'll try my best though.

Quote
If I got it correctly some of you folks come from another project and have an already established pipeline... Using Blender, right?

Using Blender yes, but the pipeline hasn't been defined yet. Right now it's still all in my head. I should have enough time after march to dedicate myself to this task and write guides and provide needed files and similar.

Quote
A): Do we already have a standard T-Pose for characters?

Hmm, what exactly do you mean by the standard t-pose. The model, the skeleton?

Quote
B): Are we going to use a single rig/skeleton -for all human/non-human critters, for example.
Or different skeletons for three phisical types
Or male and female rigs
Or three rigs for male and three for female?...

This hasn't been discussed yet. In an ideal world I'd go for three female and male rigs but in the end it all comes down to how much work the artists are willing to accept. Being overambitious + with a general lack of artists in open source is not good. We will also have to take into account the amount of animations each type will need + different types of apparel they will wear. For example: 6 types x 20 animations (very modest amount) x 3 apparel types x 8 direction x n frames/animation already results in many many sprites. In the end I think we'll set ourselves a more modest goal, but all of this is yet to be discussed.

Quote
Do you already agreed upon critters animations range? I mean, are we going to have Hit_Back/Hit_Front and so on Fallout style?

No such decision yet. We have to wait for the rule-set (and possible actions) to be completed and then see how many animations per critter we'll need.

Quote
As far as Stand_Idle is concerned: Random animation à la Fallout or continuous à la Diablo?

Basic idle would be a minimum, everything else is welcome eye candy, but not critical to have (especially depending on how many other animations we'll have)

Quote
Are we going to hide the character weapon in the Run animation?

Not yet decided. In combat, we might have 3-4 "move" animations alone. Combined with 3-4 weapon types.. a lot of animations. Hiding is an option, but it doesn't look as cool Smiley

Quote
Any established code to identify animations?

I don't understand this, can you elaborate a bit more?

Quote
Err... Eight orientations for critters, right?

Yp.

Quote
Maximum frames number for animations? Fixed or editable framerate?

Maximum not yet set. Most probably editable framerate.

Quote
Preferred format (bmp, png...)?

.png

Quote
Will the engine do something like read .PNGs according to a code, or are we going to pack them in some way (.FRMs style)?

No packing, the engine will use the .png files directly.

Quote
Is movement going to be handled by sprites à la Fallout, or is the engine going to actually move our sprites?

I don't exactly understand this. An explanation would be appreciated.

Quote
E): Any sprite editor? I don't think we're going to develop a dedicated tool, right?

No sprite editor, no plans for a dedicated tool. The engine currently uses .png images with .xml definitions how to handle the images.

So far there are a lot of open things. Right now the engine is usable, but doesn't support certain features we'd like to have, features that would allow us to be constructively lazy when creating the graphics. (some of them can be found here)

I addition, things will also depend on our ruleset, especially the amount of animations per character. And then also how much glitter we'll want to have with our graphics. All in all, there are many things we need to define and we are not yet ready to handle art contributions. One thing I'd like to avoid is to attract loads of artist only to not be able to give them any work - it's very demotivating.

You are of course welcome to contribute, just take into account our very early stage of development.
Logged
zenbitz
Community member

Posts: 1164



View Profile
« Reply #2 on: February 22, 2009, 05:40:41 PM »

Quote
C): Do you already agreed upon critters animations range? I mean, are we going to have Hit_Back/Hit_Front and so on Fallout style?
Standing stance only?

Welcome... I think this is not really decided upon.  I have some notes in the mechanics section about how many different types of actions a character can in combat. 

I am not sure what you mean by "hit back" and "hit front" - do you mean different animations depending on relative position of attacker/defender? 

I think everyone would agree "more animations is better" but we will obviously set out a priority list.  For example, we will need running animation for sure.  "Cabbage juggling" animation would be lower in the priority list.
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
Sirren
Community member

Posts: 365


View Profile Email
« Reply #3 on: February 22, 2009, 06:26:07 PM »

Hello Lamoot.
Yep, it's me. I'm a former Anim8or user. After a while I felt the need for something more Hig-Tech. I tinkered for a while with Carrara5 (which I managed to buy dead-cheap)... Not an option in my opinion. Blender wasn't an option for me, either. I know it's a complete package which is constantly growing better and better but... I never managed to cut through its interface. XSI Foundation was the cheapest fully developed package on the market at the end of 2007. It took some 14 months and a handful of training kits to tame it. So, here I am.

Fine, let's try to go with some order:
I read the matirial about rendering/lighting setup in order to get consistent sprites: it's something I didn't consider. I'm positive that we'll be able to solve this, even if I'm afraid it will entail a lot of try and error.
Files:
Lately I felt the need for a script to render my critters for Fallout, something which applies an animation clip, gets the character, rotates it, and renders the sprites in newly created folders- instead of doing it by hand. I know it can be done but I have nothing serious yet: I managed to burn both my main and backup PCs in a few days. I never had to actually establish a pipeline, so I don't know what's needed to speed up things. For the chronicle XSI scripting engine supports VBS and Python plus some more stuff.

A) T-Pose: I suppose we're going to animate a character and re-use the same animations for more critters... We'd need to model each character in the same neutral position in order to rig more characters to the same skeleton without much hassle. I was thinking something like this: let's keep a zero frame at the beginning of each animation - and start posing at frame one. At this point we simply export/save the skeleton and animations and rig the various critters.

B) Different skeletons: Well, there's not much known about Fallout1/2, but I got the feeling they used a single male and a single female rig. Practically all human critters show approximately the same phisical type. We could go after this solution, even if more types *probably* is a simple matter of bone length. We should revise manually all our animations though.
Just to know: are we going to animate by hand or use motion capture?

C) Identification code: In Fallout animations are identified by the two last letters in the animation name. For example A is used for unarmed, K for heavy weapons. So:
******AA means unarmed Stand_Idle
******AB means unarmed Walk
******KA means heavy weapon Stand_Idle and so on. This is how the engine can identify and use the animation it needs.

D) Movement handling. Rendering for Fallout I can have the model to actually walk along a path, render it and pack everithing in a .FRM file read by the engine. If you open a walk .FRM you'll see the character to actually move to point A to point B.
I know that in other engines you can have a critter to walk on the spot. It's the engine which actually moves the various frames. The Fallout method requires careful offset trimming. Walk and run animations are only two hexes long and you risk strange results when the critter stops moving, I.E. the standing critter won't be centered on the hex grid - and it will hop in place after a while.

That's all for now, thanks for answering my questions Lamoot.
See you.

P.S.
Hello zenbitz. In short: yes, that one too, at least for a critter being hit. I actually meant the full range of animations, from Stand_Idle to weapon shooting and so forth.
See you all.
Logged
mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #4 on: February 22, 2009, 07:49:04 PM »

AFAIR images were moved by the engine in Rio de hola so you didn't need to "hardcode" movement in the animation itself. So this could be used for PARPG as well.
Logged
Sirren
Community member

Posts: 365


View Profile Email
« Reply #5 on: February 22, 2009, 11:18:20 PM »

Hi mvBarracuda.
So it's an option. I know nothing about the actual coding of this stuff but I feel it's better to choose the most simple codewise. The Fallout method is hard but you'll never see feet sliding on the ground. On the other hand you'll see this in commercial projects... Jagged Alliance 2 comes to my mind. This is probably a choice to be made by your programming team.
One more thing: Lamoot talked about ".png images with .xml definitions". What's that?
Logged
mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #6 on: February 23, 2009, 07:18:19 AM »

If we end up using FIFE (which is not 100% set in stone before a programmer gets involved and evaluates the engine based on the engine requirements that we're currently compiling at the wiki), we would render the 3d models and save the rendered images as PNG files.

While the PNG files just contain the image data, additional XML files are used to specify important details of the animation sequence:
* Sequence of PNG files that belong to the animation.
* Frame-rate (called "delay).
* An internal ID that is used by the engine.
* Image offsets.

You can see an example here:
http://mirror1.cvsdude.com/trac/fife/engine/browser/trunk/clients/rio_de_hola/objects/agents/bee/attack/000/animation.xml

Furthermore the concept is described in detail in this article:
http://wiki.fifengine.de/Map_Format#Animation_File_Structure
Logged
Sirren
Community member

Posts: 365


View Profile Email
« Reply #7 on: February 23, 2009, 12:30:48 PM »

Got it, it sounds clear enough.
Are there other 2d engines out there? I mean stable,  full featured and *free*?
I guess there are, but if I got it correctly just to understand how an engine works is no trivial task.
Logged
mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #8 on: February 23, 2009, 12:56:24 PM »

There are other engines out there, but considering that Python as programming language and the isometric 2d look are set in stone, so far only GemRB seems like an useful alternative to FIFE:
http://linux.prinas.si/gemrb/doku.php

Last but not least there is always the option to create a specific engine for such a game based on open source libraries such as pyglet or pygame. However FIFE & GemRB seem to offer a far more complete package compared to creating something "from scratch" (it's not really from scratch as we would be using existing libraries but there is a difference compared a real engine package nevertheless). But it all comes down to find a programmer who could evaluate our choices and make an informed proposal that we could further discuss after that.
Logged
Lamoot
Community member

Posts: 161


View Profile
« Reply #9 on: February 23, 2009, 03:53:47 PM »

Quote
I read the matirial about rendering/lighting setup in order to get consistent sprites: it's something I didn't consider. I'm positive that we'll be able to solve this, even if I'm afraid it will entail a lot of try and error.

Yp, this is something we'll have to work on. I already took this into account when thinking how to allow people to use non-Blender programs to render sprites. Creating the Blender rendering setup is one of those things I'll be able to do after march and only then we'll be able to work on setups for other applications.

There is already a possible candidate for the rendering setup, which is used by open anno. They've produced some nice sprites using it so it's production proven. Of course it will need to be extended/enhanced to suit all possible future parpg needs. Here are some examples (models made by open anno team):

some ship
some building

Quote
Lately I felt the need for a script to render my critters for Fallout...
The XSI pipeline will be entirely up to you, as long as the end result fits with the rest.

Quote
A) T-Pose: I suppose we're going to animate a character and re-use the same animations for more critters... We'd need to model each character in the same neutral position in order to rig more characters to the same skeleton without much hassle. I was thinking something like this: let's keep a zero frame at the beginning of each animation - and start posing at frame one. At this point we simply export/save the skeleton and animations and rig the various critters.

Yes, this seems like an efficient way to produce stuff. I have a possible candidate for our "Adam", a basic human mesh, already rigged, but nothing has been decided yet. Perhaps you will prove to be better for this task. All in all, important things, such as the basic male mesh and skeleton will need to be easyly available to anyone wanting to contribute to parpg. It won't be hard to share meshes between applications, but we'll have some more problems with the skeletons/animations.

In Blender the approach is to make the skeleton in a separate file and then link it to other files, where it can be freely animated without the worry of corrupting the source file. This way there's no need to keep the frame 0 blank. Of course this is how it's done in Blender. In XSI, you'll have the freedom to do stuff as you think is most convinient/productive/organised.

Quote
Practically all human critters show approximately the same phisical type. We could go after this solution, even if more types *probably* is a simple matter of bone length.

I don't think it's just the bone length, but also the "personality" of the animation that changes.

Quote
ust to know: are we going to animate by hand or use motion capture?

By hand most probably. Nobody here has any experience with mocap and there's a needed infastructure to be able to do this. In the end, the characters will be maximum of 100 pixels tall. Can we really benefit that much from mocap (which brings its own sort of trouble)?

One thing that I should perhaps mention: The reason why no proper decissions have been made in the graphics department is because I'd like to define the needs of the project and then the pippeline properly and this takes time. The more work we invest in these early stages of development, the less problems we'll face later on + with a proper  production pipeline it will be much easier for other people to contribute to the project.
Logged
Sirren
Community member

Posts: 365


View Profile Email
« Reply #10 on: February 24, 2009, 12:04:41 AM »

Hello there.
@ mvBarracuda:
I simply thought it was better to stick to something already known. I'll gladly leave the matter to a programmer anyway. There's already somebody on the way, did I get it right?
@ Lamoot:
I saw the OpenAnno samples you posted and I really like the result.
I'm growing more and more worried about the rendering cosistency... Expecially now that Marcus is joining in. Three people and three packages...
I downloaded Blender (no python installed) and I made a little test. Directx seems the only format shared between Blender and XSI. I made a cylinder, rigged it to a couple of bones and made a simple animation. I tried to export the result to .X with various settings. No matter the settings I only managed to load the mesh in Blender. I'm positive there were no bones/animation. I really don't know if the "flaw" lies in Blender or in XSI.
Should we find a workaround then we could model and animate in our packages... At this point we'd be able to load a preset Blender scene, import the stuff wee need and run a script to render everything. I think this would be the best solution for any non-animated model, anyway. We simply need to set a reference for models size.
Just for the record: XSI can export to Max with full animations on.
On the other hand I'm glad we're not going to use MoCap.
See you
Logged
marcus
Community member

Posts: 19



View Profile
« Reply #11 on: February 24, 2009, 12:22:11 AM »

with technology still being wrote I guess we don't need to worry about it too much yet but it needs to be thought out either way. Most 3D apps can export and import OBJ, so for static meshes I'd simply go with that and remap any textures that belong to that mesh.

As for rendering, its simple really but a little time consuming: the Lead artist would set up a scene in their app used for rendering scenes, his/her machine is used for every render involved in the game, that means passing files to him/her. Obviously if we all used the same application then a render scene (...set up by the lead artist) could be passed to the other artists and renders could be done on an indivdual basis (but I don't think thats going to happen any time soon). All renders would still need a check by the lead artist for continuity but it would do the trick. The render scene would simply be a locator for snapping any models to 0.0.0 (if the model isn't already at the origin) and would have a few scene lights set up.

As we all seem to be using different apps (which is inevitable with the amount thats out there) then I'd suggest we simply pass files to the Lead, who can then import them into a render scene to batch out.

Animation is always a problem but again...can be dealt with. it just means, If I make an 30Frame death anim, I could freeze each frame onto the mesh and remove the skeleton. I'd then just export the 30 OBJ models in sequence ready to pass to the Lead for render - abit like a movie when you export it out as a Jpeg sequence and have all the indivdual frames exported out).

There are was around these things.
« Last Edit: February 24, 2009, 12:24:47 AM by marcus » Logged
Sirren
Community member

Posts: 365


View Profile Email
« Reply #12 on: February 24, 2009, 10:45:25 PM »

Hello Marcus.
I made a quick test with XSI and it can export an animation to .obj automatically. If we're to render creatures this way we should find a way to import them automatically too. I don't think that impoting an animation frame by frame would be a viable pipeline...
Logged
marcus
Community member

Posts: 19



View Profile
« Reply #13 on: February 24, 2009, 11:01:19 PM »

oh yeah, I was just thinking out loud really at possible solutions for animated models - especially if the models are are going to rendered off just one machine.
Logged
Lamoot
Community member

Posts: 161


View Profile
« Reply #14 on: March 01, 2009, 12:36:55 AM »

Any idea is welcome, this way we'll see what options we really have to transfer stuff between applications.

The approach to only render stuff in Blender seems interesting, it cancels the needs to have different rendering setups accross different programs.
Logged
Pages: [1] 2
Print
Jump to: