Wijitmaker
-
Posts
9.673 -
Joined
-
Last visited
-
Days Won
10
Posts posted by Wijitmaker
-
-
Ok, I've got Max working finally!
Note to self: Thanks to this link - http://forums.cgsociety.org/archive/index.php/t-247858.html
So, this is what an imported skeleton should look something like. I've included the geometry points for reference.
Does this help?
I see blender has the ability to export a .fbx file? Is it capable of opening one as well?
-
Try exporting a .dae file and I think it could be used to read the names of the hierarchy structure as the .dae file sees it.But since I'm not at home, I can't try to get an animation ingame. So I'll post the code here, if anyone could try it and see if it works, it would be really nice. -
The source files for all the max animations are already in the Art SVN repository. Anyone with an active Max account should be able to reopen the .max files and export a .dae from it.Then if someone wants to redo the animated PMDs in COLLADA *and* provide the source .blend or Max file for other artists to use, they would be my hero. -
I'm afraid the best I can do is get you an export of what it should be like. I'll try to figure out how to do that. Though it might be easier said than done... My 3ds Max isn't working at the moment and I think I have to reinstall windows to get it up. I've got some cdilla issues.
-
Blender treats bones as a unique object, but i'm not quite sure what you mean by 'bones as a mesh' - could you link me to some info about that? Thanks for your help
Well, this that max does that might be a max only feature. For example, if I created two simple boxes (similar to like what is started with when blender opens up each time) and if I linked one box to another box... this effectively creates a hierarchical structure of bones. If you re-sized these boxes you could make it more like the shape of an... arm for example. Max then allows you to apply a modifier called "skin" to the mesh you want to modify with animation and define this simple hierarchy of boxes as the 'bones'. That is one option, the other option is to actually use the bones object in max that help automate a lot of things for you like scaling and IK constraints.
Does blender allow you to create a hierarchy out of geometry that could later be turned into "bones" that would allow you to rig your model and apply envelopes and vertex weights - or are you forced to use bones?
-
Well, I took a look at blender tonight, and it looked as foreign to me today as it did 5 years ago. I was able to figure out how to import a .dae model (I picked one of the male tunics I think - they are all the same, so it doesn't matter). When I delete the mesh and look at the bone structure that was imported, it is awful. Bones aren't oriented correctly links are off... etc. I don't think the software's import is working so well.
Anyway, there might be a way around that. Let me ask you blender guys this - can you make any object (geometry) a bone in blender or is a bone a unique sort of an object? If so, what I could do is export Character Studio's bones as a mesh and they could be imported and linked up in Blender later? The importer seems to do fine with geometry...
Notice the bones orientation is off and the dotted line links between the bones. They look like one point is correct, but the other end of many of the bones in the spine area, the ends of the appendages, and the props are flying in the wind.
-
Just an FYI, the tool that was used prior to Atlas to make maps (SCNed) had the ability to import a black and white height map. It would be nice to have this functionality restored, enabling users not just to plug in RMS generated height maps, but also real world height maps (both at a continent level and at a battlefield level).
Bryce was a neat old tool used to generate some great height maps, having some cool features like erosion. May be worth a look.
http://en.wikipedia.org/wiki/Bryce_%28software%29 (looks like there might be a free limited version out there?)
-
Similar to Michael's suggestion. Perhaps remove the hull of the ship (temporarily) while to get your rig set up. Once the oars look right, move the hull back into position.
-
I had another thought today on this reading the RMS map thread Michael posted about the problem of to many trees.
Would it be any advantage in having a second 'forest dynamic border' (unvisible to the player) that is based on trees? This could possible block out clumps of areas that the pathfinder could omit from it's long pathfinder calcuations? This would be a Boolean default property in the actors that 90% of the units in the game would be constrained by.
Dunno - not being a programmer, I'm purely conceptual. Just a thought, I have no idea if it would actually work in code
-
I don't know. I'm not very confortable messing around the skeletons.xml file
(Still need to figure out what to do.) Any help would be really appreciated. It is hard for me to give you instructions because I don't know enough about blender to see what your seeing. I guess I could install it and try my theories myself, but I'm a total noob with the software. It would be worth a start though perhaps. Could you point me to a download of the same verion of the software you are using?
Also, here this might be worth take a look at. This is the basic structure of the dude:
http://trac.wildfiregames.com/wiki/ArtDesignDocument#Tools
The portion of the file you would be looking at is:
1 <skeletons>
2 <standard_skeleton title="Standard biped" id="biped">
3 <bone name="root">
4 <bone name="pelvis">
5 <bone name="spine">
6 <bone name="spine1">
7 <bone name="neck">
8 <bone name="head">
9 <bone name="DUMMY_headnub"/> <!-- kept for binary compatibility with PSA files -->
10 <bone name="l_clavicle">
11 <bone name="l_upperarm">
12 <bone name="l_forearm">
13 <bone name="l_hand">
14 <bone name="DUMMY_l_finger0">
15 <bone name="DUMMY_l_finger0nub"/>
16 </bone>
17 </bone>
18 </bone>
19 </bone>
20 </bone>
21 <bone name="r_clavicle">
22 <bone name="r_upperarm">
23 <bone name="r_forearm">
24 <bone name="r_hand">
25 <bone name="DUMMY_r_finger0">
26 <bone name="DUMMY_r_finger0nub"/>
27 </bone>
28 </bone>
29 </bone>
30 </bone>
31 </bone>
32 </bone>
33 </bone>
34 </bone>
35 <bone name="l_thigh">
36 <bone name="l_calf">
37 <bone name="l_foot">
38 <bone name="DUMMY_l_toe0">
39 <bone name="DUMMY_l_toe0nub"/>
40 </bone>
41 </bone>
42 </bone>
43 </bone>
44 <bone name="r_thigh">
45 <bone name="r_calf">
46 <bone name="r_foot">
47 <bone name="DUMMY_r_toe0">
48 <bone name="DUMMY_r_toe0nub"/>
49 </bone>
50 </bone>
51 </bone>
52 </bone>
53 </bone>
54 </bone>
55 </bone>
56 </standard_skeleton>
57
58 <!--
59
60 The <skeleton>s must specify all the bones that may influence vertexes of
61 skinned meshes. The <bone name> is the name of the bone in the relevant
62 modelling/animation program. The <identifier> name is used to determine
63 whether this <skeleton> applies to the data found in a given model file.
64
65 <target> must be the name of a bone in the standard_skeleton identified by
66 <skeleton target>.
67
68 The hierarchy of bones is mostly irrelevant (though it makes sense to match
69 the structure used by the modelling program) - the only effect is that
70 the default <target> (i.e. when none is specified for a given bone) is
71 inherited from the parent node in this hierarchy.
72
73 -->
74
75 <skeleton title="3ds Max biped" target="biped">
76 <identifier>
77 <root>Bip01</root>
78 </identifier>
79
80 <bone name="Bip01">
81 <target>root</target>
82
83 <bone name="Bip01_Pelvis">
84 <target>pelvis</target>
85
86 <bone name="Bip01_Spine">
87 <target>spine</target>
88
89 <bone name="Bip01_Spine1">
90 <target>spine1</target>
91
92 <bone name="Bip01_Neck">
93 <target>neck</target>
94
95 <bone name="Bip01_Head">
96 <target>head</target>
97
98 <bone name="Bip01_HeadNub"/>
99
100 <bone name="Bip01_L_Clavicle">
101 <target>l_clavicle</target>
102
103 <bone name="Bip01_L_UpperArm">
104 <target>l_upperarm</target>
105
106 <bone name="Bip01_L_Forearm">
107 <target>l_forearm</target>
108
109 <bone name="Bip01_L_Hand">
110 <target>l_hand</target>
111
112 <bone name="Bip01_L_Finger0">
113
114 <bone name="Bip01_L_Finger0Nub"/>
115
116 </bone>
117 </bone>
118 </bone>
119 </bone>
120 </bone>
121
122 <bone name="Bip01_R_Clavicle">
123 <target>r_clavicle</target>
124
125 <bone name="Bip01_R_UpperArm">
126 <target>r_upperarm</target>
127
128 <bone name="Bip01_R_Forearm">
129 <target>r_forearm</target>
130
131 <bone name="Bip01_R_Hand">
132 <target>r_hand</target>
133
134 <bone name="Bip01_R_Finger0">
135
136 <bone name="Bip01_R_Finger0Nub"/>
137
138 </bone>
139 </bone>
140 </bone>
141 </bone>
142 </bone>
143 </bone>
144 </bone>
145 </bone>
146
147 <bone name="Bip01_L_Thigh">
148 <target>l_thigh</target>
149
150 <bone name="Bip01_L_Calf">
151 <target>l_calf</target>
152
153 <bone name="Bip01_L_Foot">
154 <target>l_foot</target>
155
156 <bone name="Bip01_L_Toe0">
157
158 <bone name="Bip01_L_Toe0Nub"/>
159
160 </bone>
161 </bone>
162 </bone>
163 </bone>
164
165 <bone name="Bip01_R_Thigh">
166 <target>r_thigh</target>
167
168 <bone name="Bip01_R_Calf">
169 <target>r_calf</target>
170
171 <bone name="Bip01_R_Foot">
172 <target>r_foot</target>
173
174 <bone name="Bip01_R_Toe0">
175
176 <bone name="Bip01_R_Toe0Nub"/>
177
178 </bone>
179 </bone>
180 </bone>
181 </bone>
182 </bone>
183 </bone>
184 </bone>
185 </skeleton>
186
187 <skeleton title="XSI biped" target="biped">
188 <identifier>
189 <root>Biped_GlobalSRT</root>
190 </identifier>
191
192 <bone name="Biped_GlobalSRT">
193 <target>root</target>
194
195 <bone name="Biped_Spine01">
196 <target>pelvis</target>
197
198 <bone name="Biped_Spine02">
199 <target>spine</target>
200
201 <bone name="Biped_Spine03">
202 <target>spine1</target>
203 </bone>
204 </bone>
205 </bone>
206 <bone name="Biped_Lshoulder">
207 <target>l_clavicle</target>
208 </bone>
209 <bone name="Biped_Lbicept">
210 <target>l_upperarm</target>
211
212 <bone name="Biped_Lforearm">
213 <target>l_forearm</target>
214 </bone>
215 </bone>
216 <bone name="Biped_Rshoulder">
217 <target>r_clavicle</target>
218 </bone>
219 <bone name="Biped_Rbicept">
220 <target>r_upperarm</target>
221
222 <bone name="Biped_Rforearm">
223 <target>r_forearm</target>
224 </bone>
225 </bone>
226 <bone name="Biped_neck">
227 <target>neck</target>
228
229 <bone name="Biped_head">
230 <target>head</target>
231 </bone>
232 </bone>
233 <bone name="Biped_Lthigh">
234 <target>l_thigh</target>
235
236 <bone name="Biped_Lshin">
237 <target>l_calf</target>
238 </bone>
239 </bone>
240 <bone name="Biped_Rthigh">
241 <target>r_thigh</target>
242
243 <bone name="Biped_Rshin">
244 <target>r_calf</target>
245 </bone>
246 </bone>
247 <bone name="Biped_Lhand">
248 <target>l_hand</target>
249 <bone name="Biped_Lfingers"/>
250 </bone>
251 <bone name="Biped_Lfoot">
252 <target>l_foot</target>
253 <bone name="Biped_Ltoe"/>
254 </bone>
255 <bone name="Biped_Rhand">
256 <target>r_hand</target>
257 <bone name="Biped_Rfingers"/>
258 </bone>
259 <bone name="Biped_Rfoot">
260 <target>r_foot</target>
261 <bone name="Biped_Rtoe"/>
262 </bone>
263 </bone>
264 </skeleton>So... if you notice in the code above, there are 3 sections (Philip please correct me if I'm wrong here). Rows 1-56 is defining the standard biped. That is a generic biped that the game engine uses.
Rows 75-185 is the 3ds Max version of the biped. It is saying for example... in row 100 & 101 that 3dsmax bone named: Bip01_L_Clavicle equals l_clavicle on the generic biped (see row 10).
Rows 187-264 is the XSI version of the biped. It is saying for example... in rows 206 & 207 that XSI bone named: Biped_Lshoulder equals l_clavicle on the generic biped (see row 10).
Sooooo, what I foresee for Blender is a similar variant that is like the 3ds max and XSI versions that will need to be created. It would have the same number type, size, constraints, etc... of bones (this can hopefully be achieved by importing an existing .dae file) - however you can rename the bones as Blender requires (maybe it doesn't care?). Once the changes are made you need to make a bit of code to tell the game engine what the new bone names equals on the generic biped.
Hopefully that is somewhat sensible... let me know if you need some clarification.
Is there a reason for that limitation? With COLLADA now, shouldn't we try to let things be animated without the need for bones/rigs? I remember whem Modding C&C Generals, just the name you give to the object within the model - Like a Turret - it would move and act like a turret. If the game is to be mod friendly not all animations should be required to work with bones.In the past we had requested programming to support vertex animations. I'm not sure what the status of that is or ever will be, but that would accomplish the same thing. In the short term, for an immediate solution, we have the ability to create as simple one bone animation/rig that would effectively do what you want to do. It just isn't something as easy for the artist as exporting an unboned vertex based animation.
-
It's not - the only thing you can animate is bones.
There you have it! I haven't really had a need in the past to do such an animation, so I don't think you'll find baton twirling to be frequent motion
there are also a bazillion unused animation files in the Art SVN. Maybe Wijit can give some insight on how to use these or modify these.Yes, there are numerous motion capture files in the repository. I forget the format, but I believe some of them could work with blender (though most were intended for max and it's Character Studio software). These aren't perfect, but they provide some great fluid animations. I used many of them with slight alterations (to get them to repeat and loop properly, shorten to one action per animation, etc...).
-
I think it may be possible to animate the prop point nodes. I've never tried it. Only one way to find out though
Nice work with your first ever animation!
This shouldn't require any coding, what do you think you need to code?
-
Agreed. If you could make a blender version of the default humanoid then any animations make in blender would be able to be applied to the existing .dae models and vice versa - any existing animations of humanoids could be applied to new blender humanoid models.
-
I think it shouldn't be to difficult to import a .dae into blender. I know that there is some issues getting the .dae animations into blender... but does that mean that the file doesn't open at all? Or, can it at least load up even if none of the animations work? These things I don't know.
If you import a .dae head from the game, you should be able to snap him to the position of blender's head bone. We seperated the head from the body because the body uses the alpha channel in it's map for player color, while the head uses the alpha channel in it's map for random object (hair) color. The game engine can only use the alpha for one thing at a time.
Anyway... Once you import a head, snap and attach it to the head bone. When you animate the head bone the imported head should follow. I'm using 3ds max terminology, but I'm sure Blender has something similar.
About the boat, it isn't as difficult as you think to sync them. Just ensure that the number of animation frames in both the boat animation and the fisherman animation are the same. Also ensure that the animation speed defined in the actor file are the same. If those 2 factors are identical they should be sync'd. You should be able to work with them both in the same scene in blender. The only trick is to select what you want to export when it is time to export to .dae and then "export selected" to separate them from each other into different .dae files. At least that is how I would do it in max.
Your blender rig looks pretty good, but something is going on with the hands there... perhaps the hand bones are rolled over or twisted and it is distorting the wrists?
When your creating a rig, note when you import a .dae file from the game. It should come into blender with some dummy objects that are being used as nodes to define prop points. These nodes are linked to the skeleton, but are not exported with the mesh/skin so they aren't rendered in the game.
-
I'd be happy to help, but I fear my advise would be outdated and it is 3ds max specific, not blender. The blender guys could help you I think. All the old 3d max animation, rigs, and original files are in the SVN art repository.
for your questions... if you create a sword, you put it's origin at the handle of the sword. When you define what prop point the sword is attached to in the actor.xml file - the game engine will do that for you. You don't animate the sword, it simply moves with the actor's hand.
for your boat and fisherman... I would create two seperate rigs. One that animates the boat. The boat would include a prop point that would be the bottom of the foot location of the fisherman. The fisherman and his movements would be his own animation that shares the same skeleton as all the rest of the humanoid characters in the game. This would allow you to perhaps use that fishing animation by a guy who isn't on a ship, and maybe on shore.
There isn't anything super fancy about the skeletons.xml file. I think one of it's main purposes is to allow cross compatability of .dae files and different software packages and their unique rigs. For example, a standard named rig out of XSI software can be common with a rig out of 3ds max (biped).
The heierachical bone structure between animals could be shared by the skeletons as well. For example, a goat and a deer could have the same skeleton because they would likely have the same number of bones and joints. Elephants and camels would be different because they have unique bones for things like an extra long neck or a trunk. Boat rowing skeletons could be shared across all boats. Siege units, and chariots could each be common... etc. Alas I fear I'm not explaining myself well... let me know if I can provide more guidance.
-
Great work! Keep it up!
mreiland = Michael Reiland
Former Programming Leads:
Raj = Raj Sharma
H20 = Daniel Wilhelm
Dak Lozar = Dave Loeser (tragically passed away August 2004)
I sent you a PM with some old old information. Though they contributed in the early stages of the game and their contributions may have now been replaced... 0 A.D. would not be what it is today without their contributions.
Edit: doh - Philip beat me
-
While your at it fix the logo at the top of the forums too... GAMES is the wrong font
http://upload.wikimedia.org/wikipedia/en/e/e2/Wildfire_Games_Logo.svg
-
Now that is cool
-
I think that would be a fantastic addition.
These were features we were planning to include years ago:
http://trac.wildfiregames.com/wiki/XML.Entity.Actions.Attack
http://trac.wildfiregames.com/wiki/XML.Entity.Actions.Move#Run
Trample was intended to be a "damage" aura that was going to be coupled with the stamina (run capability) of the units.
Accuracy was to be a function of unit class, rank, distance, formation, etc. Philip has done some pondering on this in the past: http://www.wildfiregames.com/forum/index.php?showtopic=12669&view=findpost&p=204807
Many of these features were implemented in the pre-simulation rewrite in 2009. After the re-write I suspect they haven't been given a priority to be re-implemented.
Another advanced attack features to consider are elevation bonus to the unit that takes the higher ground, also the direction of attack. Face to face combat is best case vs. an attack from behind which would cause considerable more damage.
-
These are two interesting articles:
http://wildfiregames.com/0ad/page.php?p=1587
http://wildfiregames.com/0ad/page.php?p=1594
Follow that up with this: http://www.dailymail.co.uk/sciencetech/article-1332636/DNA-tests-Chinese-villagers-green-eyes-descendants-lost-Roman-legion.html
-
Good discussion, sorry if this has been brought up...
When the group reaches its target, it'll spread out into a wider rough box shape if there's enough space to do so.What if the formation does not reach it's target, if it is confronted by an attack or comes to a unpassable object (wall/water/forrest), will it stay in column, or assume the designated formation?
-
Great, glad you like them. Re-reading this topic I now realize there were two separate people making the request. Ganon, if you are out there shoot me an email and I can send them to you too.
-
Shoot me an email, I think I can dig it up for you and reply with an attachment.
-
If you have any specific questions, I'd be happy to answer them.
WFG wasn't directly affiliated with SCNPunk, WFS was focused on modding - not scenario design. However, they "sponsored" us which allowed us to get website and forum hosting through Heaven Games. We (Tsunami, Woad Creations, etc..) were a part of the SCNPunk Network.
Reverie Studios (initially lead by Micah H.) and WFS didn't really have a direct connection other than we launched into game development around the same time and had roots in AoKH. If I recall correctly Konstantin (EX-T from SCNPunk) didn't join Reverie until a few years later.
I think there was a little friendly competition in the early days that encouraged both groups to make some great progress.
Missing and unused data files
in Game Development & Technical Discussion
Posted
For the unused animations... is it possible some of the files are duplicated and used in another folder? Many of them look like they are unused because we are waiting for return of the run/stamina feature.
Animations are a precious commodity so I find it odd that any are not in use.