trespasser dino creator

[Remdul]

I actually painted blood on it's little head, but when I palletized the texture the color changed a bit. I'll try to alter the palette color instead, might work.

Have given up on importing the compy for today. The TMP export script messed up on my version of 3dsmax, so I'm forced to work with .3ds files exported from MAX. However, .3ds mess up the vertices, creates extra ones. And my app can't select multiple vertices with the same coordinates, so the skin totally messes up. Trying to fix this by reducing the vertex count (sharing coordinates, like .3ds files should) but that messes up other things as well...

[Rebel]

Yea, I somewhat figured that you'd hit a bump or two along the way. 3ds files seem like damn nightmares. Hopefully, you'll be able to get the tpm prob. straightened out --

[Remdul]

Ah, at least I figured out why there are so many verts in .3ds files;

Faces on my mesh; 370
Verts in exported .3ds; 1110
1110 / 370 = 3

Three, so each freaking face has it's own vertices!

* Whoa, something even worse; each of those double vertices has, seemingly, a tiny random value added to it so it doesn't *exactly* match the coordinates from it's duplicate vertex. That explains why my vertex comparison code didn't work (I assumed that at least the coordinates would still be the same). I just hope that this is related to rounding up and down numbers, and not deliberatly coded by whoever wrote the .3ds export plugin.

Anyhow, I realised I still had to reduce the number of vertices, because the weights are stored in the t-scripts of cource. So if I'd worked around it then the huge amount of script code would slow down the games' performance as well (even though it is pre-processed/compiled at level loading time).

[Remdul]

Whoohoo! The import worked!

Thought I should share the moment with you, took this screenie a split second after the level loaded;

http://home.planet.nl/~buijs512/trescom/compyskin1.jpg

But when I took a step back I noticed it still needs a bit of polishing;

http://home.planet.nl/~buijs512/trescom/compyskin2.jpg

Lol. Well, at least I've straightened out some stuff.

Is there a way to keep the bone roations/positions intact even as the dino is alive and kicking?

Also, my comp was droping to the floor alot, couldn't walk more than a meter without doing so. Think you can fix that? Maybe we can make them jump by changing the elasticity value on the body box, so everytime they drop they 'jump' up.

Btw, each time the compies bit me they bounced back, quite a realistic response.

* My app is now working like a charm. There are probably be a bunch of other things I can change, we'll see what the community, the end users will come up with by then.

[Rebel]

Say, great news, Martijn! Congratulations, too.

I imagine that it'll take a little experimentation on our parts to get them to work as we wish, but thanks to your perseverance we're well on our way.

*Try changing the float speed of dino to float speed = 0.750000 or something like that. The animal is smaller than a raptor which may be why it's trippin' over itself. Elasticity might work, not sure for jump. Are you certain that you have all of the joint statements correct, too? int NumJoints, NumDoubleJoints?

*Second screenie, the compy's neck and head looks flat? Accurate, or fluke screenie?

The x3 factor for vertices doesn't make alot of sense, the faces share those vertices, don't they?

[Remdul]

Well, each face has it's own three vertices in the .3ds file. You usually want to share vertices with the same positions to save memory...

Second screeinie; that was actually the problem. I rigged the skin with an altered bone system, but the engine overwrites those when the dino is animated (i.e. alive). I should use a different bone system, the one from the Para, that one has the kinda bone system I need for the compy (though not sure that dino can be scripted to attack Anne).

Got all of the joint statements correct. I simply copied the bones from the Albertosaur without actually altering them (exept for the positions, but apparantly that doesn't matter anyway).

Speed value makes sense.

Elasticity didn't make much difference though. Doesn't seem to be possible to change some properties on the dinos body/head/tail objects (tangible, movable, mass etc.).



I have uploaded the final beta version of the app:

http://home.planet.nl/~buijs512/trescom/tpdc.zip

Included is the compsognathus model, including the old raw tpm export (the one with the messed up vertices/faces) and a working version for testing.

[Rebel]

Nice progress report, bub.

You can use the Para if that's what you need, Rem. The only thing that stops a Para from attacking is the archtype being 1 instead of 0. That, not only turns it into a carnivore, but allows other scripting associated with raptors to be included and used there.

Dino worked, though geomadd did mention 4 degenerative triangles listed in its printout. I love its death pose, lays alot cooler than normal death pose. I noticed that its mouth hadn't moved or opened.... just how does that animation sequence work itself out? I never thought of that aspect of the dinos before this. Dino needs a bit of work, but the fact that it works at all is astonishing by itself.

*btw, I used these vocal cubes in lieu of standard ones. To use, just delete whatever dino cubes have the int Dinosaur = 5 from the cubes, that is, if they even exist in the test level that you're using. [/url]

[Remdul]

Ahh, I see. Starting to understand that stuff now...

I bet that's the reason I was hearing that irritating metal bat sound whenever the compy was moving around in the testscene.

I didn't rig the compies mouth no, just went thru it quickly. By no means a final version of the dino.

Reminds me, will collect and upload a bunch of sound files I've extracted from JPOG and Chaos Island.

[Rebel]

Yea, each dino is assigned a # (except raptors, by default they're int dinosaur = 0) which corresponds to used vocals. I think the albertosaurs cubes are perfect for the ceratasaur.

*btw, how come no assignments for the $Jmodels in the tscripts? Aren't they used as direct assignment to animations, such as

int A00 = 11
int A01 = 125
int A02 = 145
int A03 = 147
int A04 = 207
int A05 = 146
int A06 = 121

I assumed (and obviously, I'm quite stupid at this stuff) that they equated to the bones system and told the engine which bones were in use and in need of animation. I'd love to understand this properly, so if you care to explain, I'll listen.

*Oh, love those ribs showing thru the skin.

[Remdul]

Hmm, lets see...

int A00 = 11 points to the 11th vertex of the model
int A01 = 125 point to the 125th vertex etc. you get the idea

The engine automaticly detects and links bones to an dino like this;

-the dino skin has name "Albertasaur"
-engine searches "$J<name dino><number>" and links the bone to this dino until it has "int NumJoints = <number>"
-probably does the same thing for "int NumDoubleJoints = 1"
-also links any shadow models/joints in the same way

So if we'd call our compy skin model "Compy" and the bones like this: "$JCompy00", "$JCompy01" it should work. I bet that if you remove the shadow model on existing dinos it'll still work, because the engine uses whatever it can find and if it isn't there it simply ignores it.

Only now I realize why the number of joints and double joints where specified. I thought most of the bone names where hard-coded, but it seems to be a more dynamic system.

But anyway, when the dino is animated, it probably applies the pre animated/physic controlled rotations per bone, which on their turn transform the linked vertices.

I wonder how exactly the bone system itself works. I mean, the engine must for example know which bone the knee elbow, or jaw, or any other jaw is. It must know which bone the parent or a child it. I think they might be hard coded, per type of dino or maybe the following values might have to do with it:

Anim00 = 7
Anim01 = 8

I *think* those are indices to parent or child bone (e.g. the hip bone > knee bone > ankle bone) or might be some other information related to dino animations (obviously). I'll check on this right away...

Another interesting idea; the animation scripts. They wheren't used in the original levels for some sort of cutscene, they might have been used *somehow* to animate the dinos (it must have had a purpose afterall). I think I'll have another look at this thing...can try to compare data of a compiled animation script (maybe it has some sort of a uniform header) with data inside .scn files, or even the exe....

Good thing you asked, only now I'm starting to have an overall idea of the entire system...

* the Anim values don't seem to have anything to do with parent/child indices. Some dinos don't have any of these values at all (Brachs). The values don't seem to be higher than the number of bones, but not sure that has anything to do with it.

** Strange. I removed the Anim values on our compy, and now they all have a huge lump on the back of their heads. Used the bones cheat, the bone are the same as before I changed this. I'm not entirely sure what the value could be...

*** Changing the Anim values has the same effect in many cases...

[Rebel]

Thanks for the info. That gives me a better idea as to the inner mechanics of a dino.

*I seem to recall a term 'reverse knees' in the exe somewhere.



Try the compy file below. (needs to be scaled down, forgot. 1.5 or a little less seems ok)

http://www.trespasserextras.com/compy.ZIP

This shot reminds me of the alien movies.

[Remdul]

Lol, yeah that was also the first thing that popped up in my mind as well.

Your compy looks a bit better. Did you use another bone system?

[Rebel]

Yea, our alien compy is actually using the para's bones system. A very stiff skeleton (no double joints?), so not sure that'll work for your compy. I think the compy that I uploaded was using a raptor's bones.

*I also noticed that lowering speed does help that tripping problem too, but if the foot bones aren't in correct positions, ie. not low enough in foot, that causes the dino's feet to ride just below the terrain and the exe generated $foot models are not trodding along the terrain's surface but keep interacting below it, which causes a trip.

[Remdul]

Ah, that makes sense. Great job Rebel.

[Andres]

Nice going Remdul

I think my reasoning for not having a b=<name> list like materials was that it is no use - bone #1 _cannot_ be named anything other than "$J<dino_name><num>". So it seemed like a waste of space listing those as they don't change and can be generated so easily from <num> and <dino_name>.