-
Posts
2.755 -
Joined
-
Last visited
-
Days Won
47
Everything posted by historic_bruno
-
There's something called "baking" the animation, what do you think? http://blenderartists.org/forum/showthread.php?200371-Rigify-Auto-rigging-system-new-and-improved&p=1887716&viewfull=1#post1887716
-
I can assure you, you do have OpenGL or the window would not even start (not to mention you'd have to try very hard not to have OpenGL these days) But it's an ancient version (1.3), the drivers must be equally ancient and bugs can't be ruled out. DirectX shouldn't have any impact because we use OpenGL exclusively for rendering, since DirectX is not available for other OSes. Can you try changing some graphics settings in default.cfg? I can't promise it will make a difference, but it's worth trying. Settings of note are renderpath and novbo. The current thinking is that it's a driver bug, the crash actually occurs in a GL call (glDrawElements), so everything but your graphics card, drivers, and our code are basically irrelevant I'm not so sure we aren't doing something subtly wrong, but it's not something everyone can reproduce - in fact it's quite rare. The biggest help might be to get a newer computer, or a really cheap but decent replacement graphics card. I got an Nvidia Geforce 7600-ish PCI for my ancient dying computer, before eventually replacing it, but that helped for a while.
-
Because of this part of fisherman.dae: <library_controllers> <controller id="rig_Mesh-skin" name="rig"> <skin source="#Mesh_181_kl-mesh"> <bind_shape_matrix>0.4865988 0 0 0 0 -7.9277e-8 -0.4865988 0 0 0.4865988 -7.9277e-8 0 0 0 0 1</bind_shape_matrix> <source id="rig_Mesh-skin-joints"> <Name_array id="rig_Mesh-skin-joints-array" count="29">DEF-head DEF-hand_L DEF-forearm_L_01 DEF-forearm_L_02 DEF-upper_arm_L_02 DEF-shoulder_L DEF-upper_arm_L_01 DEF-hand_R DEF-forearm_R_01 DEF-forearm_R_02 DEF-upper_arm_R_02 DEF-shoulder_R DEF-upper_arm_R_01 DEF-neck DEF-ribs DEF-toe_L DEF-foot_L DEF-shin_L_01 DEF-shin_L_02 DEF-thigh_L_02 DEF-toe_R DEF-foot_R DEF-shin_R_01 DEF-shin_R_02 DEF-thigh_R_02 DEF-spine DEF-thigh_L_01 DEF-thigh_R_01 DEF-hips</Name_array> <technique_common> ... The most important being the data in rig_Mesh-skin-joints-array, which to get into really technical details of the COLLADA spec, is a list of the SIDs (not names!) of bones/joints for which inverse bind poses are provided in the model, and which can be used for vertex weighting. Note there are 29 IDs in the above array and there are 29 pose transforms in rig_Mesh-skin-bind_poses. Those IDs are looked up in the scene nodes, ignoring the ORG/MCH bones. All of our existing models work the same way, though with a different numbers and names of bones. Unfortunately adding to the confusion in this example, the IDs and names are not identical for the bones, the game expects the exact names (not IDs!) in skeletons.xml. This info is external to the rigify tool or Blender, and according to the COLLADA spec. The reason it's this complicated is that you might want to share data between multiple models and animations in the same scene - a bit overkill for us As far as why there are so many extraneous bones, it's perfectly legal COLLADA to have nodes/bones that aren't used in the animation, and in this case Blender dumps all the bones in the scene to the COLLADA document, even though most other apps have no practical use for them, the exporter doesn't know about rigify. The bones do have specific meanings though, for which you need to read the rigify README (in scripts\addons\rigify) I interpret this to mean: when animating in Blender after using rigify, only animate the ORG bones or those you create. This is because the ORG bones will automatically transform the others as appropriate, only in Blender. But they don't directly control the skin/mesh, the DEF bones do that, which is why they are assigned the importance in the COLLADA document.
-
Wouldn't it be much easier to just make the rig by hand and match existing bipeds in the game? I think you would already be done
-
If it's the same file, then your latest posted skeleton won't work, because it still doesn't get the bones names correct (it leaves off .01, .02, etc. on the end of some of them). I don't know if it's clear or not, but you know that you can open the DAE file in a text editor? I recommend something like Notepad++ on Windows and set the language to XML so you get nice syntax highlighting. If you're only looking at the names in Blender, they might be different.
-
Known bug, here's the report.
-
Oh I don't think it should be required to do this just to get a model in the game, by any means. That's just the way it is until we change it That actually looks quite close, but the tags don't all match up, and also "DUMMY_headnub" isn't needed and will likely cause problems. I don't have your current model to test, but here's what I came up with (formatted nicely and slightly corrected): <standard_skeleton title="blend-biped" id="blend-biped"> <bone name="root"> <bone name="hips"> <bone name="spine"> <bone name="ribs"> <bone name="neck"> <bone name="head"></bone> </bone> </bone> <bone name="shoulder.L"> <bone name="upper_arm.L"> <bone name="forearm.L"> <bone name="hand.L"></bone> </bone> </bone> </bone> <bone name="shoulder.R"> <bone name="upper_arm.R"> <bone name="forearm.R"> <bone name="hand.R"></bone> </bone> </bone> </bone> </bone> <bone name="thigh.L"> <bone name="shin.L"> <bone name="foot.L"> <bone name="toe.L"></bone> </bone> </bone> </bone> <bone name="thigh.R"> <bone name="shin.R"> <bone name="foot.R"> <bone name="toe.R"></bone> </bone> </bone> </bone> </bone> </bone> </standard_skeleton> <skeleton title="Blender biped" target="blend-biped"> <identifier> <root>root</root> </identifier> <bone name="DEF-root"><target>root</target> <bone name="DEF-hips"><target>hips</target> <bone name="DEF-spine"><target>spine</target> <bone name="DEF-ribs"><target>ribs</target> <bone name="DEF-neck"><target>neck</target> <bone name="DEF-head"><target>head</target></bone> </bone> <bone name="DEF-shoulder.L"><target>shoulder.L</target> <bone name="DEF-upper_arm.L"><target>upper_arm.L</target> <bone name="DEF-forearm.L"><target>forearm.L</target> <bone name="DEF-hand.L"><target>hand.L</target></bone> </bone> </bone> </bone> <bone name="DEF-shoulder.R"><target>shoulder.R</target> <bone name="DEF-upper_arm.R"><target>upper_arm.R</target> <bone name="DEF-forearm.R"><target>forearm.R</target> <bone name="DEF-hand.R"><target>hand.R</target></bone> </bone> </bone> </bone> </bone> </bone> <bone name="DEF-thigh.L"><target>thigh.L</target> <bone name="DEF-shin.L"><target>shin.L</target> <bone name="DEF-foot.L"><target>foot.L</target> <bone name="DEF-toe.L"><target>toe.L</target></bone> </bone> </bone> </bone> <bone name="DEF-thigh.R"><target>thigh.R</target> <bone name="DEF-shin.R"><target>shin.R</target> <bone name="DEF-foot.R"><target>foot.R</target> <bone name="DEF-toe.R"> <target>toe.R</target></bone> </bone> </bone> </bone> </bone> </bone> </skeleton> Also, if you try this and it doesn't work, please paste the errors you get from interestinglog.html, it will help point us in the right direction.
-
Have you updated the source code recently? ogl_shader was removed in 10984 and there's been a few more recent changes that might help. That still leaves a lot of errors
-
According to your error, it's not I've never heard of SYSROOT, if it's something that gets passed to e.g. ./configure, that's a step before the compilation and means the build system is indeed responsible for configuring the path correctly. Apparently there's a variable called "PKG_CONFIG_SYSROOT_DIR" which tells pkg-config to prepend something to its paths, can you try setting that and see what happens? It's listed here under Environment Variables.
-
Some of the unit animations might seem a bit off, either the actors need tweaking or the animations need some work (we haven't had many people working on animations until quite recently, and to my knowledge no one has touched the biped/human animations in quite some time).
-
How do you mean? If you look at chicken.dae, you'll see the node names exactly match the bone names in BlenderChicken (they match the hierarchy as well, but skeletons.xml indicates the order of the bones isn't important, only the names). They aren't prefixed with DEF, ORG, MCH, etc., because (presumably) a different process was used to create that rig. You can't just make up names, the game isn't smart enough to know which bone belongs where "rig_Mesh-skin-joints-array" in Daniel's fisherman.dae lists the only bones we can animate in the game (only those with bind pose transforms), and they all start with DEF-, which is why I suggest those in particular.
-
Premake uses pkg-config to get the include paths for various packages like libxml2. So what's the result of running "pkg-config libxml-2.0 --cflags"? Are the other dependencies that use pkg-config compiling the correct files?
-
Oh, yeah, you can do that if you make a new <standard_skeleton> and a matching <skeleton> for however many bones your current rig has. Are the bones still all named like "DEF-", "ORG-", etc? That's what I meant when I said the skeleton bone names have to match what's in the DAE.
-
Note: i.e. if you have less than 29 targeted bones in your skeleton it will not work Also those skeletons don't match the bone names from fisherman.dae, or am I looking at the wrong file?
-
Progress reports on funded work
historic_bruno replied to Ykkrosh's topic in Game Development & Technical Discussion
I think it would be nice to have some non interactive characters in the game to provide the appearance of bustling towns and cities. They could walk around, in and out of buildings, and of course flee in terror when a raiding enemy approaches It wouldn't add anything to gameplay, but it might be fun eyecandy to watch. -
Illustrator/ Concept Artist
historic_bruno replied to JustinOperable's topic in Applications and Contributions
Can't wait to see what you come up with Justin. Hannibal is indeed an awesome character -
Missing and unused data files
historic_bruno replied to Ykkrosh's topic in Game Development & Technical Discussion
Does anyone on the team have 3DS Max? I for one do not At least some of the remaining skeletal PMDs (horse.pmd, mastiff.pmd) appear to have the original max files in the art SVN as you say. Anyone able/willing to convert them to DAEs? Edit: Here are the remaining PMDs converted to DAEs: skeletal.zip Not all of them had skeletons.xml entries so it's impossible to recover the rig :/ -
Crash or freeze when fort built close to border
historic_bruno replied to Patricius's topic in Bug reports
Which OS and version of the game? The more info the better -
Missing and unused data files
historic_bruno replied to Ykkrosh's topic in Game Development & Technical Discussion
There's about to be A LOT fewer PMDs around. If anything breaks terribly, blame me -
About biomes: we should definitely factor out the hardcoded terrain textures and resources from random maps, as much as possible, there are some vague ideas about this on the Wiki. What I'd love to have someday is high level controls to define parts of a random map with different biomes, before placing any textures or resources, then tweak some variables (forest cover, water cover, hills, etc.), then place the textures and resources as a final step. Your random biomes might get used as part of that concept
-
Ah, indeed corrals do have a ResourceSupply component.
-
precompiled mac version done
historic_bruno replied to cc_julian's topic in Applications and Contributions
Yes, this was the conclusion we came to as well, the existing code is messy and cobbled together from a number of bad ideas Unfortunately the one who was working on a complete rewrite of our sound API seems to have disappeared, so progress is stalled. -
Importing Terrain
historic_bruno replied to MishFTW's topic in Game Development & Technical Discussion
Can you export the height map as a BMP? I know we have discussed adding the option to import BMP heightmaps into the game. The advantage of a BMP is it would be easy to edit one in an image editor, but perhaps we could support other data formats too.