A really obscure theoretical question... Created 18 years ago2005-10-02 00:17:29 UTC by Gackt

To begin, this has nothing to do with my current project - I'm considering doing another on the side, but before I start, I want to make sure it's possible.

I've done many, many attempts at vehicles in the past, and most of them have worked to some degree. I've done APCs, planes, even an X-Wing with working S-foils (but the game crashes when you fly upsidedown ). All of them have used the principles of thruster-driven movement.

Now, what I want to try to conceptualize is a bi-pedal vehicle; essentially, a mech. Ignoring humanoid qualities other than legs, is it even possible to create a movement system that would accomodate even flat terrain? Multiple func_door_rotating's with brushes attached don't work, since the brushes pass through the ground. My next idea was an arrangement of balanced phys-prop brushes, held together by contraints as "muscles", with some sort of force (perhaps parented func_trains, if that is even possible) moving the legs in a constant movement. To accomodate falling over, some thrusters could be used to push the mech back into an upright position.

However, I've not explored such complicated movement systems before, and perhaps someone out there already has. If anyone has a single clue or even a whimsical comment about how a walking vehicle - however rigid it might be - could be accomplished, please give me your opinions...before I start working on something that will fail late in development.

You will need a constraint system, unless your sitting on top of a supercomputer :). I think the entity is called, phys_constraintsystem, or something like that...

Other than that, no, I don't really have any ideas. Just try not to use phys_boxes.

Good Luck.

Thanks for the advice - I'll let you know how it turns out (I will run a very basic test sometime soon). If anyone else has an ideas, they are more than welcome.

Yeah, I'd say make good use of the constraint systems. Their proper setup wil l be crucial here - For without them you'll run some long and costly VPhys calculations. I'm sure something like this could be accomplished (Cables and ropes for muscles might work better, actually), with some thought. You'll want to get acquainted with the phys_ set of entities, as well - They will be your good friends for this situation I'd wager.

I'm sure with some clever parenting and entity work you could pull this off.

I think this is possible! After all a plane, car etc can be made so why not a mech with some thrusters and constraintst to hold it all together!
My only concern in lag and dodgy movement.

Same here - just look at my Tumbler demo map to see such principles in action (the dogdy movement bit, that is). It was good of you to mention the lag issue, Habboi, because I wouldn't have thought of that before (besides, an entire level's resources devoted to 1 mech and nothing else would be kind of boring). I've been doing some visualizing about leg movement using cables, and it is starting to come together in my mind. I already have a good idea of what I want it to look like, and if I can just pull off convincing leg movements, then the rest should come easily. Again, I'll let you know the results of my upcoming test soon

I have now run several basic tests that evaluated the efficiency of multiple leg-moving ideas. Unfortunately, all of them were hindered in one way or another.

There is one major idea I think has the most potential - a purely mechanical leg with no thrusters - but it has a fatal problem. First, we start off with two long rectangular brushes (the calf and thigh of the leg), connected to each other at their ends by a special axle. The axle is actually 2 axles physically linked by a brush, and they fit into special holes cut into leg brushes. These holes have their bottom halves open so that there is room for the link between the axles to move. The axles are kept from falling out by "hubcap" brushes that are larger than the axle hole.

The idea is that a tracktrain (the top axle), which can have its movement points parented, will move in a special path that represents the position of a human knee joint in various stages of taking a step. Since the leg brushes are physbox, they should follow suit - but they don't.

Therein lies the problem - the physboxes fall off of the axles, even thought the hubcaps technically hold them in place. I have tried rigid lengthconstraints, but it doesn't seem to keep them in place. Any ideas on how to stop this? Also, keep in mind that - if the entity should be changed from physbox - I need the leg brushes to be solid to the players and the world, since they will be making constant contact with the environment and the others.

Got pics to show?

constraint with -1 breaking limit

Sorry, I'll have some posted later tomorrow - please realize that I'm a 28.8kbs modem user, so uploading even images to a hosting site takes a while. I'll follow The Hunter's advice and see what happens, and then post some screens.

SUCCESS!!!!!!!!!!!

The Japanese phrase "Yattaze!" is the only thing running through my mind right now. I have successfully created a moving tracktrain axle with physically simulated calf and thigh brushes attached (and still moveable)! The secret is using the flag "no pitch" to keep it from turning 45 degrees from how it appears in the SDK (which explains why the physboxes were falling off - the calculations to keep them on in such an instantaneous rotation would have been ridiculously complex given their weight). For retaining their physical properties, The Hunter's suggestion of a phys_constraint was essential. While in reality I ended up using a phys_lengthconstraint with normal, non-rigid rope strength, Hunter's suggestion of -1 for the breaking limit ensured that those suckers weren't going anywhere.

Now, what this means is that I will be able to simulate a human leg as it takes a walking step. However, I think this will be just for show, since I don't think the legs will be able to create enough friction to actually propel the mech (this mech is intended to be agile, not a Mechwarrior tank). The next problem, therefore, is propulsion. I'm already considering thruster arrays, but there is also the problem of keeping the mech upright while balancing on moving physboxes (although the phys_keepupright seems like it may do the trick).

In that respect, does anyone have any alternative suggestions for propulsion? Your help has been greatly appreciated so far, and the Eureka moment I just had a few moments ago (ironically while listening to "Breakthrough" by Coming Century) has made this my new main project. Christmas_Manor can wait until...well, Christmas! I've got a 30 foot tall mech to build

I happen to design products in Technology Graphics and Materials which has tought me many designing techniques.

My point is that if you want it to stand then like real-life things you must have a bigger base e.g. a mobile phone stand, if the area that holds the phone is bent back then in theory it will fall back...BUT if it has a big long base to hold it up then hoo rah it stands...

Same goes for HL2...IF you have a big enough base to support the weight then my theory is that your mech will walk and stand straight IF you balance the weight out with a big base on the feet...
Kinda like duck feet

That will be tricky - I've been building the feet first to make sure the tracktrain works on the final version, and it doesn't have a wide base for feet. It actually looks similar to a high-heeled shoe, only it doesn't have a pin-prick-sized rear support (the support is just 2 units narrower than the front). However, the design for the mech requires this - the foot has a joint that separates the front sole from the rear sole, allowing the "toes" to curl somewhat when it lifts the foot. I decided early on that I wasn't going for a huge, Godzilla-sized mech (it will be about 4.2 Freemans tall), so I'm hoping that by making smart design choices from the beginning, the mech won't be top-heavy.

Once I finish making a leg (it's quite a long process, because I'm making the final version of it), I'll post an image and perhaps a demo map for everyone to have a look at.

So far, so good - I've virtually completed the left leg. It has more articulation than your standard action figure - 5 joints just one leg! To more realistically simulate a human step (and just because of the way my mech's foot was designed) it has three joints in the foot, allowing it to curl downwards as it pulls up. It also has the primary joint in the knee, and also one that connects it to the hip of the body casing. The physics seem to be working as I imagined, although the real test will be when I add the path_tracks and get those babies in motion. I'd post images, but I want to save the surprise of how (in my opinion) cool it looks for when it actually works

Just thinking out loud, and I'm all for trying to do things for the sake of doing them, so keep at it, but, just for me, wouldn't it be easier to make in a modeling program... like the buggy and waterboat? I guess I'm asking how would Valve have approached your project? How would they solve it?

He could do but this is an experiment to see if it can be made with brushes! I'm actually interested by this idea and look forward to the end result if it works

Actually, I'm terrible with modelling programs and choreography. I don't even do much scripting or entity work in Hammer, either - I'm strictly an architecture fanatic. I also have a habit for building things on a massive scale that never get finished, so this project is a new experience for me.

However, I've met with great success so far, so I'm fortunate I don't have to go out and learn how to use modelling programs in order to accomplish this. While there are still a few variables in the future, the major concern - the legs - has been all but taken care of, so I'll keep going. Even if the worst should happen and it doesn't work in the end (highly unlikely), it'll make one heck of a statue for my levels

Now that I'm finishing up the legs, I get to do my favourite part - the chest/pilot seat. Everything I've learned in previous maps will be used just in that one area, and - as a tribute to RavenT's interest in my earlier attempts at a pirate ship - it will use a variant of my cannonball "technology". I'm even going to try for contextual damage - for example, if you shoot the head, you'll eventually take out the camera that serves as the pilot's eyes. It's going to be a lot of fun.

Good luck, I want to see this when it's done

I'm displeased to announce that I have encountered my first set-back.

While the tracktrain method with physboxes worked in my intial test, it is not compatible with the complexity of the finished product. The physboxes do not stick to it despite constraints, and there is - as you had mentioned, Habboi - some noticable lag due to physics calculations whenever the mech is jolted (i.e. with the manipulator). This is very sad, because in theory it IS doing exactly what I wanted it to do - the foot curls like it is supposed to, and everything is attached fine...just that the knee is not following its joint.

I wish this were under different circumstances, but here is a pic of the present leg and its path_tracks so you can see how it is meant to move: http://photobucket.com/albums/a136/Gackt_C/?action=view&current=MechLeg.jpg

Does anyone know of a substitute for physboxes that I could use? It has to be able to rotate when told or otherwise move like a calf/thigh would on a person (perhaps on its own track...). Can you think of another method, if necessary, of moving the leg brushes along with the joint?

It's weird to be replying to myself, but I think I may have found a solution. I'm experimenting with having the calf and the thigh as entirely self-contained tanktrains, with no joints connecting them (other than a loose lengthconstraint). My problem is this - is there anyway to "pose" a tracktrain while it is en route? I know I can change a variety of angles, but I have to keep it in a fixed direction so that it will not rotate sideways when it spawns. The rest of the leg is working fine under this system - the physboxes on the foot still curl and that sort of thing. I just need to be able to make both of the leg pieces look like they are connected at the same joint by rotating them independently. Any suggestions?

Sounds like a really complex and hard thing. Have you tried the phys_hinge constraint already, plus constraint managers to keep the constraints from working against each other?

Other than that, I'd definitely would've modelled this and written code for it. It looks like just too much work with too limited things to me. But hey, you learn things experimenting with this and it's interesting to see how it's going...

EDIT: Looks like a nice mech-styled leg bytheway...

Thanks - I can't say it's 100% original, but just being able to recreate it was hard enough. The overall design is based roughly on the Arm Slave called Arbalest featured in Full Metal Panic: The Second Raid, but mine will have a much different head, weapon array and a re-done paint job (black with neon blue, I'm thinking). Speaking of FMP:TSR, the opening animation is actually what inspired me to make this mech (I've been mulling it over for a long time, but I've put it off due to technical - at least I thought - impossibility). Also, as I mentioned before, I'm a complete newbie to modelling, so I'm just sticking with what I know - Hammer - with surprisingly good results.

As for the phys_hinge, how would you use that in relevance to this situation? Are you thinking of putting it between the two pieces....wait, I think that IS what you're thinking. I've not had much luck with that entity in the past though - how would you set it up, assuming you're just dealing with a phsybox that has been constrained to a tracktrain?

This is becoming more of a developer diary than a troubleshooting topic

On that note, I've made another surprising breakthrough with an equally interesting entity - func_rotating. I had used it during my initial tests, but I deemed it inferior to the tracktrain method because it was somewhat sporadic. However, I turned the calf brush in its entirety into the func rotating, and it began to spin the entire leg 360 degrees. This is, of course, not desirable, but it demonstrated potential - the lengthconstraints had just enough give to look like there was some flexing going on at the joints (even though they no longer exist, much to the physboxes' delight I'm sure). Early on, I controlled them using time-stopping, where after a fixed period of time I told the func_rotating to stop. This worked very well, but I couldn't see how it would apply to the grand scheme until now.

I'm going to try and set the calf and thigh as rotating brushes that move back and forth automatically at fixed intervals. The lengthconstraints have made the feet wonderfully automatic, so now I only need to concern myself with those 2 main pieces. I'll report back once I have seen how it works in real-world tests. In the meantime, if you have any further suggestions, don't hold back now

Just a quick question: how do I make the effects of a button's outputs automatically repeat?

My test theory is working, but only once per button press. It basically goes forward for .6 seconds, and then goes backwards. I want to make that action loop, but right now it goes forward, but then goes backwards for eternity.

Try a logic_timer? What I would do is replace those func_rotatings with a Func_rotating_door and see how that works.

Phys_ballsocket might help you since it mimics, among other things, a hip or shoulder joint.

Sadly, the func_door_rotating idea was a physics disaster (I'm still shaking...and the mech's leg probably is, too :). I tried using the phys_ballsocket, but it isn't parent-able, so it won't function the way I need it to.

Unless there is a way to make the func_rotating's more controllable (I'm running cockpit simulations now, so I'm testing how it works when you move forward), I'm going to have to give the idea up. Since it may come to that, I'm trying to rethink the movement scheme of the leg. I will attempt the tracktrain leg method again, and this time I'll see how I can get them to rotate around the joint origin. If anyone has an alternative idea for this, by all means, tell me.

Ironically, I'm back at square one - and it isn't a bad thing.

What I mean to say is, I'm using the original movement setup (physbox leg pieces constrained to a tracktrain), only this time it WORKS. Instead of making the axles in the legs as the train, I made a separate brush that is textured with nodraw and is very small. Also, I replaced the very complex axle connection that joined the leg to my test cockpit, which was one of the reasons it failed at the beginning, with the phys_ballsocket that [VDC] Rad Brad suggested, and the results are much better.

Now, the only problem - other than setting up a true-to-life movement path - is to get the constraints to stop fighting each other. I know this will require constraint systems, but I truly don't understand how they work (Hammer's description is clear, but I am having trouble fitting it in my project's context). Mind you, I'm going to try to make it work right now, but I don't think I'll get great results. Anyone have a "for Dummies" explanation?

P.S. once I have this problem worked out, I WILL upload a sample map so you can see all of your intellectual contributions working together to power the leg

is to get the constraints to stop fighting each other.

For example, when a wooden lat is held up by two phys_lengthconstraints (say, it's held up by ropes), you would use a phys_constraintsystem entity that both phys_lengthconstraints refer to as their constraint system. This will stop them from fighting each other.

Also, you may have noticed this already but maybe not, there are several example maps in the sdk folders, quite some cover physics entities.

I hope that helps a bit...

I should have remembered about the SDK maps...thanks for bringing that up.

Anyway, I've got the leg doing its basic movements now, and the main problem is keeping it from twisting around. I'm just happy I'm at the point where I am now - the movement system works, now it's just fine-tuning (and a LOT of it, as things are going now). I also eliminated a joint on the foot, so it moves more like a human's would (it used to bend right before the ankle, where that brace-thingy with yellow decorations on it is in the screenshot). I'll report back when I've made more progress.

you going to use this in some big map to blow combine apc`s and stuff to bits?

As near as I can tell, it's Transformers! (More than meets the eye!)

Nope. The mech is intended, as was dm_castle's "secrets in the walls", to give me the upperhand against my friends in our too-infrequent LAN matches. Mind you, it's all in good fun, but I like to make a big surprise in my maps, so imagine if you will a secret hangar in a wide field suddenly opening up and me climbing into a mech, ready to kill everyone and anything. I'm going to make a really flashy start-up sequence that will dazzle anyone who's watching.

I'm not making any headway just yet on it, sadly. I have to give my wrists a break, but once they're fine again, I'll get back at it. I have some rethinking to do - I just want to get the legs OVER WITH already.

BTW, Transformers? Do you enjoy making an already-impossible mapping project even MORE complicated? If you want to try, be my guest - we'll have a mech battle afterwards

you can have driverble things in HL2:DM?
i might make a tank...(not by mapping in vhe)

Aka the car / jeep and airboat...
Hehe now that would be a big shock! Haha i'm in the lead, oh yeAHHH!

Doors open! OMG OMG RUN RUUUUN
Lasers, big explosions and HUGE legs stomping the other players now that would be super cool!

If your gonna finish this then may I suggest because of lag you make a crap map with just a grass floor thats HUGE...Then when they play it they go omg this map is crap so you surprise them hehe!

I believe the map was called drob3 e.g. part 3 as it contained 3 maps and the third had a mech...

Ok I remember this map that had a HUGE mech and I mean huge, it was for SP and used like tracktrains to move, it had huge guns on the hands and stuff...
Argh what was it called
It was on Snarkpit and stuff, i'll look in my maps folder now for ya!

cs_mechwar, I believe.

I have not played a working version of it (the mech was invisible and the missiles were missing their textures, but its effects have been described to me (I got an idea from the screenshot when I downloaded it, but I didn't spend enough time playing the map to figure out what was going wrong with my copy). I think the map creator was going for something more along the lines of Mechwarrior mechs. Mine's based on more contemporary Japanese mechs. This one is the basis for my project: http://www.full-metal-panic.com/hangar/hangar.php

Keep in mind that my colour scheme in the final edit will be quite different and I have many features planned that aren't in that mech (but not some that it DOES have that I wish mine could). I don't like the head, so that will change too. Either way, prepare yourself for a wild ride in a fun, hopefully agile mech.

And yes, Habboi - I will be sure to put it in a relatively non-complex map. Perhaps I will use my Christmas Manor with an extended field...that could have some funny reprecussions.

My wrists are a bit better now, and I've relocated my PC to a much more egronomical desk (I was using a TV tray for my mouse and keyboard until now), so I'm going to see what I can do to the leg. I think the main problem has been that I have tried to make the calf move, which requires the thigh and foot to both align properly. If the thigh is the one being moved, the calf and foot can be easily ball-socketed and the problem is solved (I hope). Wish me luck...I'm running out of ideas :

cries

I can't believe that I've forgotten how I made the tracktrain pull the calf physprop forward...but I have. None of my maps show any relation between the 2 entities, and the posts I have made don't allude clearly enough to it.

My dear, dear mech...how shall I ever save you? And just when I had the idea that might have reversed my fortunes...

Well, it's back to the lab...

.... ...... ....... ....... ....... .........

I HAVE DONE IT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

The above sequence of smileys illustrates the radical transformation of my emotional state within the last 5 minutes. Through a breakthrough discovery, I have discovered "THE" problem with my mech's leg! All this time, all these solutions...none of them worked because they weren't addressing what was really at fault. And what was, you may ask?

The placement of the tracktrain itself.

I had been thinking all along that the joint in the calf/thigh connector brush was the track, even though I knew it wasn't. This caused me to be blind to the fact that the tracktrain was actually a meter or so away from the movement track, or that the train's movement track was NOT appropriate to its position (which directed the leg to curl vertically backwards - therefore, it was the cause of the instability). I have begun tweaking its position and also the movement path, but one thing is clear - the mech's leg IS working, and it is for REAL this time.

I don't want to submit a sample map while it is still in need of so much readjustment (to erase all the errors I made "fixing" it), but once it is at least on a satisfactory level, I will post it for you all to see. Thanks for all your support and comments up until now - I hope the mech will live up to all expectations! I'll let you know when it's ready!

Yay!!!!

i want to know how the player gets to the top?

I thought of that early on, so don't worry. I don't have any permanent setup yet (since I have yet to start the body of the mech), but what will happen is that the pod you strap yourself into will decend from the bottom of the mech on a platform that uses tracktrains to extend up and down (sort of like one of those toy punching gloves with the criss-cross bars that make it extend, only this will be vertical). If that turns out to be too complex for the mech to handle, then I'll just use a platform-based elevator. As far as I'm concerned, that's one of the easiest part of the mech to deal with - I can't wait to start making it!

Just to let everyone know, I have at last submitted a demo map of the mech leg as it will appear in the final version. I had to sacrifice most of its articulation, but at least it's stable and it moves somewhat believably. It will look much better when it is actually moving across terrain and not touching the same point over and over. I'm going to start the cockpit and then attach the other leg to the other side, after which I'll give you an indication of how well things are working. Until then, enjoy the map (and I HIGHLY advise against using it in Garry's mod - I did so to take the funny screenshot, and it caused havoc on the tracktrain's movement path :zonked:).