Outerra forum
Anteworld - Outerra Game => Modding: Importer, Tools & Utilities => Topic started by: PytonPago on April 16, 2013, 02:22:35 pm
-
Hi there, i just started to thing about getting stuff at my model get a bit complex in the design:
- having rigid axle suspensions (single and multiple wheels)
- gear-complex simulation (simply put, all gear rods between engine-gearbox-wheel axles-functional equipment (like a winchdrive) whyte proper rotation speed proportions of each element even to the actually set gear) (thats 3 parts for rods multiplied by 7)
- driving wheel complex simulation (at the same time the suspension works, hawing around 6 different movable parts)
- other gear driven equipment (in my case the BM-21 launcher that will be put on the chase later (maybe 12 or so))
- Motor fan rotation
- a lot of little movable things :
-- door handle
-- door window control (mech. or electronic)
-- gear setting
-- sidelights and other internal stuff (possible fans, all function-able buttons, internal GPS or control LKSs etc.)
As there will be no different model for the cockpit and at the hi-detail LOD range could be maybe 10 such vehicles doing different stuff, how does that affect hardware usage and where should I draw the line in those systems ? My ural has just a 6 wheel base (single and double rigid axle suspension):
(http://m2.aimg.sk/forig/f_441044917_f85a7342b2ea181d244136af62713a20.jpg)
(http://m3.aimg.sk/forig/f_441044910_3c6b1a3d97a6103b7a070ec8ef68341e.jpg)
(http://m1.aimg.sk/forig/f_441044900_ba802efba2ffe9de11b5c93dfd168ab5.jpg)
(http://m2.aimg.sk/forig/f_441044893_288aa1c3174313536d141dc9187386ad.jpg)
(http://m3.aimg.sk/forig/f_441044882_ec7c5dd1739280f9baace84df7325130.jpg)
(http://m4.aimg.sk/forig/f_441044867_11fc98f01770a656e46eace0c5eefdd1.jpg)
... doe, there are much more complex possibilities (a 8 or 10 wheel base whyte the same level of sim-modeling of the hi-weight crane at its back like the already described) and yes, the graphics involved to the rocket launcher at the actual one, where the controls for it are at theyr base, that i would like to be used directly there:
(http://svsm.org/albums/bm-21/P1580945.jpg)
(so it will have another set of complexly-movable meshes to the model (not so much as it horrifyingly looks like)). So generally, there is a lot of stuff that will dependently move at once and I have a bad feeling about putting that final thing to Outerra that way, but no idea how should it be simplified reasonably and still multifunction-ally at a great number of details.
There still be a little complexion added in the model itself at different levels (engine and its compartment is not finished, its a open structure vehicle, so at least a simplified engine-mock up should have been done as it is visible at a great number of angles, what was my motivation to make the gearbox-complex working the way as descried), so yes the model can end up hi-poly not looking like that at first look ..
-
You are taking this way too EXACTLY CLOSE TO REALITY as I have come to expect from a fellow Outerran. Keep up the good work and don't forget to pressure Cameni and Pig to the breaking point!
I would love full physics drivetrains to match reality. Here is one I attempted in Garrys Mod.
GM11 - Realistically Geared Tatra (http://www.youtube.com/watch?v=DSrWipEE2tg#)
-
You are taking this way too EXACTLY CLOSE TO REALITY as I have come to expect from a fellow Outerran. Keep up the good work and don't forget to pressure Cameni and Pig to the breaking point!
I would love full physics drivetrains to match reality. Here is one I attempted in Garrys Mod.
GM11 - Realistically Geared Tatra (http://www.youtube.com/watch?v=DSrWipEE2tg#)
... : P .... not so close as it seems, i just make primary objects rotate at realistic proportions to the gear set ... your way in garrys mod is a whole different thing as it simulates the gears at a (maybe something simplified, but still) real-world contact pressure gear system (yes, i had seen some engines too, made even whyte additives to fuel, nice play) ... the problem is, its a real crack on CPU, as it has to be got in OT as just some vehicle in the whole world of other simulations taking place at once, its much better to just simulate the rotation proportions correctly, where special things will be taken at aether a very well done animation, or a potential situation dependent combined-animation system (making some kind of variations at each animation, where the specific interaction places would be combination-able whyte others at a function to theyr actual position and/or characteristic constant).
.... so my point is to have some assumption of how much things can be simultaneously be done on a vehicle in this simplistic way of mine whyle not getting OT panic when a Grad battalion gets theyr salvo fired at the Hi-res model range, at the fact to have so much movable objects at the model (as i counted its just for the chasis around 60-70 pcs. plus there would be around 30 in cockpit and 30-40 around the BM-20 module) ... making sure a quarter of them is working at the same time is a little scaring to me. Not sure if OT can handle 12 such machines at once.
... and yes, I dont wont to pressure them too much, as they have a lot to do whyte the environment at the time. Still would like to have this more complex way of simming a vehicle set up, when they got ready whyte it so i can make a half-step by half-step how to for people to get the model flow started for the mil.-sim. dream of mine for test-purposes. ( ... while not making them angry enough to make me wake up some nice morning in the middle of siberia hawing a mad smiley tattoo on my hand, signed by the OT team and the message: "dont EWER get back !" :D )
-
I think a basic mechanical simulation system could work with calculated reductions / rotation proportions as long as somewhere you can define a max torque +/- and max rpm rating and that way you could actually damage fake gears, driveshafts and wheel mounts. That would be applied to all moving parts and be amazing in a game. Just do a quick monitor of 12 rotating parts / suspension components and keep track of the stresses of each. Like a damage model but much simpler and cooler.
-
I think a basic mechanical simulation system could work with calculated reductions / rotation proportions as long as somewhere you can define a max torque +/- and max rpm rating and that way you could actually damage fake gears, driveshafts and wheel mounts. That would be applied to all moving parts and be amazing in a game. Just do a quick monitor of 12 rotating parts / suspension components and keep track of the stresses of each. Like a damage model but much simpler and cooler.
Sounds like an idea. ...
-
A little step closer ... gears finally rodded ... now just to make the engine look more like real machinery, make the steering sys. and interior ... got a bad feeling about the poly-count doe.
(http://m2.aimg.sk/forig/f_441958093_73d8f672ad81cfad0926aa5d9f19fd99.jpg)
(http://m2.aimg.sk/forig/f_441958101_ebb5d05bc9b65c69da1c6d57bb481134.jpg)
(http://m4.aimg.sk/forig/f_441958107_30a2848cdc6ca058d67a848157ed93f2.jpg)
(http://m2.aimg.sk/forig/f_441958117_4980ec501ed438b1a088a7c4e2c5d923.jpg)
(http://m3.aimg.sk/forig/f_441958126_329a0d6afc84ccb36b8565a9a63ebf46.jpg)
(http://m4.aimg.sk/forig/f_441958135_e7d0275945ef89e4a9e92177b43b6c44.jpg)
(http://m2.aimg.sk/forig/f_441958237_39a388ce166fdde908a8bec8ef9c08b6.jpg)
Been a little slow lately. :P
-
I would rather have the model look AMAZING and lose 30% of my frames then look poor and loose 2%. ROCK ON!
-
I would rather have the model look AMAZING and lose 30% of my frames then look poor and loose 2%. ROCK ON!
Make Cameny and co. kill some future modellers, EYY ? Just dont take me as a target, if they give you the Tiger tank, i wont to have at least a T-34 value. ;D
I forgot to add the trencher :
(http://m1.aimg.sk/forig/f_441985348_095bc6623e122d27404337589bab606f.jpg)
-
I just got to my spare wheel ... i wont to simulate later its release from a hydraulic hold. How should i rig/setup the wheel itself, so it would after the release act as an separate OT-physic object, that could bounce down a hill ? Or should i do a separate one, that would be spawned at its place once the animated one dissapears after the release ?
(http://m1.aimg.sk/forig/f_442156700_87416f7f4703b146ddc2ab3185626c37.jpg)
(http://m1.aimg.sk/forig/f_442156696_8b3b5a2e5fe90e632f3979efbaa021f5.jpg)
(http://m1.aimg.sk/forig/f_442156680_7851ebdaa11755b5587df57d5ddfe423.jpg)
-
man I do hope Outerra can handle your level of detail, if so it'll be awesome :D
-
Pago you are just the right type of crazy.
If it can't Chaoz, we will force Cameni to make it handle it.
I wonder how hard it would be to code the actual changing of a tire. Tire damage occurs (essentially just lowering the radius of the tires and increasing the drag along the ground).. You would need to employ a jack (can be completely coded and just lift the truck BUT DON'T TRY IT ON A HILL!) then you would hold X to remove the busted tire.. Then do the same to get your new tire off the truck, car etc and walk it/roll it over and hold X to install. Remove jack and Blamo.. You would of course want to keep the broken tire for repair as buying a new one is expensive in the wasteland that is new Earth.
-
... well, if they land in Russia, they wont have a problem whyte spare parts to urals even after thousands of years ;D ... the same goes for T-34s :D The changing would be nice, great idea! Seems then the disappear-spawn method would be better then, (anims. for putting them right on will be a little problem doe, have to change the axes a little to make it possible) ... that is, if the wheel wont roll down the himalayas after releasing, whyte me running for it. ;D (will need a little fixing for it) ... getting the spare back would not be a problem, the holder is just a hydraulic lifter, so placing it back at it and getting it up is no problem. Will probably need a broken-tire model - would be classy if the tire could behave like mold-able cloth in a lighter version (would be a nicer look if broken on the move). But i still dont know - the tire should be a different model file all together then? It could be used even as a random object it seems ... :-\
-
Have good and a bad news ...
.... good is, the main model is ready (the main functional parts that is), so the work is going to just make the wheels turn, transmission rods rotating, trencher rolling, and so on ...
.... bad is, my NB is a pain lately .. for some reason it messes up the colada export out of blender (just makes the meshes stuff twisted around theyr origins for some reason), so i would like to ask someone to try do it for me (im in school-town, so till i go home it will be another 2 months to do it myself - testing season pushing too a lot) .. so export it yourselves and enjoy to play whyte it as you all like
--- freeware-modify freecence applied ! ---
And of course OT use free. :D
After school season, i will make the rigging/scripting/importing job finished then as i intend, and after this transport version runs smoothly (i may still make it a back-section later), and so, when my knowledge of scripts comes up by this 4320-31 Ural, i will go on whyte the BM-21 Tornado-G project.
And the blender file of course : Ural - base version (http://ulozto.sk/xRrTXYNX/model-zip[/url)
There is a number of buttons in the cabin, the trencher has a back-part that has to run left-right to make the rope go aligned, rods as many as it gets. But the tornado will have them numbers quadrupled it seems. :-/
... P.S.: Cameny, i would ask you to move my thread to the vehicles section, if you find some spare time please. Should probably done it sooner, but cant figure it out ... im just left-handed on forums. :-/
-
... i was just bored, so i done the back-case whyte open-able sections. Will do the releases for them working, and there would be a good thing to script the sections fall, if you dont fix em (or when you try it at an bad truck angle ... will see).
... the back-case model : ural-4320-31 (http://ulozto.sk/xdtyfP7K/ural-4320-31-zip[/url)
(http://m3.aimg.sk/forig/f_442379718_e195a2c61b9e026536845700ba5419d1.jpg)
(http://m2.aimg.sk/forig/f_442379725_c08dde6a3968cc90dfa01bf1b22753df.jpg)
(http://m1.aimg.sk/forig/f_442379736_d9a7b356678264be3707bffb4001bbb8.jpg)
(http://m3.aimg.sk/forig/f_442379746_768fc5083be6995567e64435c5cde0c1.jpg)
(http://m4.aimg.sk/forig/f_442379755_6d86cf0dbe4a85bf0f5d70d6a867d51d.jpg)
(http://m3.aimg.sk/forig/f_442379774_ea13007f77612143fd790146a621a1b7.jpg)
.. how does one make the broken wheels go interact whyte the groun ? .. would it bee enough to have two tires (normal and broken) at the model and just switching it in script, when damaged ? Or will there be a need of some other way (and if they need to be separately taken in the importer) ?
-
Broken in what way? Deflated or unmounted .. probably by setting new tire radius in script, and changing some other tire properties too.
-
probably by setting new tire radius in script, and changing some other tire properties too.
... so, scripting the "damaged" mesh appear, switching the normal tire and scripting its smaller radius/props in ? ... Did you too thought about the possibility of dynamically changing meshes (cloth hit by a ball like stuff) for OT in the future ? ... what do you thing about using such way to simulate tire pressure based deformation (or lowering the pressure from vehicle cabin to have a better run on sands) while rolling and possibly used such a thing for broken ones too ? Just thought, if it would go to load the truck whyte some heavy stuff and take it effect on the tire profile ...
Broken in what way? Deflated or unmounted ...
... well, it seems to be a bug (it just "generates" itself rotations around the meshes origins for all tiles before saving the export of any kind for some reason, making it look like twitched paper-shred - stays like that on workspace too) ... im ruining Blender on Ubuntu linux, where my graph. card isnt exactly good whyte it (not supported, hacked some functions, tho linux doesnt like much - still better than whiteout for playing in Blender) ... and it has some issues during modelling too, so im not much in uproar about that :P ... i will switch it for a colada and 3dM when i get my hands on a normal sys. later .. (will do some tuning to it anyways based on the tire/rod needs for the OT tire-change test, just giving it to forum members to play whyte )
-
You can enable/disable the meshes to show damage or a change of state, but tires would deserve a custom support in the engine, to simulate the effect of changing pressure. We were already thinking about how to approach it, together with a better tire physics, so perhaps one day. But first we have to implement the changing friction on different surfaces.
-
You can enable/disable the meshes to show damage or a change of state, but tires would deserve a custom support in the engine, to simulate the effect of changing pressure. We were already thinking about how to approach it, together with a better tire physics, so perhaps one day. But first we have to implement the changing friction on different surfaces.
... thanks Cameni ...
-
Had some little time : .. the cabin was refined into hi-detail but BM-21 Grad and the freight 2340-truck have to be separate models at the end. Will be just too big :-\ (truck has around 14 Mb data, but the grad tops 25 at this stage, so in the detail i need it will topple up to 70 - and i have no low-poly LODs done yet ??? ).
And yes, have changed my axles for possible tire changing. :)
(http://m3.aimg.sk/forig/f_443333978_7e4a7cd94c70fd8df19360aa6f52dcb0.jpg)
(http://m4.aimg.sk/forig/f_443402935_f6f66bfcfe68984b2589d646259d884f.jpg)
... I would like to ask, if there will be made some kind of "force app" - simply, the same like the crater creator, but it would just apply some pushing force to the object at the camera vector direction. It would be very helpful for testing suspensions for cars and tanks later on by excessive forces (hitting by another vehicle, falling of heavy freight etc.). If it could maybe even show how great the applied force was (maybe an grow-indicator whyle holding the mouse-button - that would be nice even for the craters), it would be really awesome. ... that would be helpful for importing functional structures and vehicles, physics testing and playing - and for me it would help to add me the back-push from rocket-fire for the grad rightly - as it could be used even script-based if vector and point of hitting defined - for the fire sequence, doe even for many other applications. And testing for munitions like this:
http://www.youtube.com/watch?feature=player_embedded&v=JA0bxgq1X2Y#! (http://www.youtube.com/watch?feature=player_embedded&v=JA0bxgq1X2Y#!)
-
Bullet physics operates with force impulses applied on the body, so in theory one could deliver an impulse to see how the model would behave, that's a good idea. Not sure how to show how much the kick was, or how to control it. Like with the craters, hold longer before releasing to get a bigger kick?
-
Explosions are always good. How about a simple UI that you can set the charge force.
-
Bullet physics operates with force impulses applied on the body, so in theory one could deliver an impulse to see how the model would behave, that's a good idea. Not sure how to show how much the kick was, or how to control it. Like with the craters, hold longer before releasing to get a bigger kick?
yes - time of holding equals forces strength ... well, the cars can hit another ones and they react quite well ... maybe a simplistic script of that interaction, white a 1kg weight imagined object, and the time holding the mouse key would multiply by some factor and yield like the 1kg objects speed in the script ( that can be even in Newtons then if derived to a 1 cm square :) --doe a 20 sec limit would be good - dont want to let someone hold the mouse button for 3 days trying to push the Earth out of the orbit ;D) ? ... The factor would be great to be chose-able too, as the tuning of that tool for heavier/lighter objects. That would help a lot.
-
Explosions are always good. How about a simple UI that you can set the charge force.
Actually, that is why i wanted that force strength be shown in some way - engines trough the simplicity have some deviation in those reactions, so i would play a little white this tool to see, how big should the force be, to push the projectile (or some object) the right way in OT compared to reality and latter apply that to the fire-script of the weapon.
-
little progress :
(http://m4.aimg.sk/forig/f_443605335_c372fffb9561ef1fcfd24d116f330ea6.jpg)
-
... i just found out, that i cant outmaneuver a rubber tube in the model - simply, on the launcher is at his base and tube-section an wire-pack, theyr meshes movements are uneven and there is no point, where i could place a cross-section prolonging between them. (the arm-connected wire on the pic.) Is there already a support for such softy objects like wires, chains and stuff ? I would hate to animate that ...
(http://i508.photobucket.com/albums/s327/dralvarhanso/100_4169.jpg)
P.S.: what are the distances for the four LODs set for models ? (sorry if i oversaw that being discussed somewhere else)
-
Got a little progress, whyte the targeting arm ... also, the two filter types of the ural series (there is a third too, a sidekick on front of the right door, will be added later too). Found seems, control will be nice from the model itself, doe, will see how the geodetic aimer turns out, but will need to texture its ranges too ...
(http://m4.aimg.sk/forig/f_444702571_c72cefcc859c65db4d90b13d6791f08a.jpg)
(http://m3.aimg.sk/forig/f_444702582_0a069e813d65da1a419022d436554018.jpg)
(http://m1.aimg.sk/forig/f_444702588_e9b87a3d6d575d970a45bdef4e0a3e0b.jpg)
Hope i get it done by the next month (hopefully whyte rockets), to finally get to rig and script it into OT ...
-
Crazy Bastard. Keep going.
-
(http://m1.aimg.sk/forig/f_444870692_092c07c852d9209b500d02c492bdc39e.jpg)
(http://m3.aimg.sk/forig/f_444870686_9e13aab5e79d764db188c3eb170059d0.jpg)
... yea, but still getting nowhere about the user manual ... the more of those panels i see, the worse it gets ??? ... damn those 20s ! We should keep our MLRS forces, now those guys are hard to find ... movement schematics and theyr controls are figured out, but those electronics. Three step fail-save and so many levers ... and the programmed pylon-launch is still a mystery. :( Seems, gonna need to make myself a spy-suspect by contacting the russian defense ministry about that ...
-
Damn you .. Now I want to build one of those boxes.
-
Damn you .. Now I want to build one of those boxes.
what, the launch box ?
-
Oh my dear great Svarog !!!! ... i newer even thought about blender being so damn angry on me to change the "textured" side of the mesh every-time i mirror it over some axis and ended up white an model that is basically fit for a trash-can. :-\
(http://m4.aimg.sk/forig/f_445620471_9b77681af37ff31b800127486dea207b.jpg)
And i thought that the conversion to the collada format was messy on my NB, finding there is an issue whyte individual pivots there (seems they changed a thing or two from the older blender versions), letting all the parts being ether spawn at the same spot whyte their origins, or laying them somehow unexpectedly wrong. Happens to me on the 2.67b when getting to two and more step parenting. (- that is the thing i described earlier, i thought it was linux messing up on me)
(http://m1.aimg.sk/forig/f_445621300_51770d903f57ef21cd752fb15e651d65.jpg)
(The lighted up parts and some around them are not parented to anything - so in right dimensions and positions)
Ether i have to change every single wrong triangle by deleting and extruding it anew or ... well i dont wont to get the thoughts even close to this one. Seems, i will stretch my project to a little longer time ...
Anyone new at doing models for the Collada import version - dont do the same mistake, export at the very beginning at modeling, import to a new session and look at the rendered faces after each step of changing the model. (Alt + Z - for blender in object mode)
-
no way to just flip back the normals or conform them? could be easily fixed n maya i think
-
no way to just flip back the normals or conform them? could be easily fixed n maya i think
... flipping them is possible, just that there is so much stuff and faces i must pick vert by vert ... and in two separate models i did. I would just give it the two-side mesh option, but OT does not support that yet (or am i out of the updates lately ?).
-
if you like you can send me some parts and ill have a look if i find a quick fix in maya. (e.g. as obj)
-
if you like you can send me some parts and ill have a look if i find a quick fix in maya. (e.g. as obj)
.. well, the way i done that model and how it looks in real render makes me doubt a fast way ... i just started to turn it right hand-picked, but if you like to play whyte it, there you go - http://www.upnito.sk/subor/df004531279ad1964d0fa8c49bbd1829.html (http://www.upnito.sk/subor/df004531279ad1964d0fa8c49bbd1829.html)
At least i made the single wheel import properly, and seems the size is like it should in RL. Just to figure some script out, so it rolls and bounces down hills. ;D
-
Just a little show in OT :D ... yes a lot of work still on that faces-problem (cabin not there) ...
(http://m2.aimg.sk/forig/f_446009725_610a5468c7248f5e8922bc974871999f.jpg)
(http://m2.aimg.sk/forig/f_446009745_4919a53bc5b37a6e21ec56dcd6af8de6.jpg)
Looking at the guy, what is its height there ? ... the door window starts somewhere at 2m (as in reality, so in blenders grid), so he seems to be about 1.70 ? ...
-
Oh my ... that face flipping took 10 years of my life by stress ...
(http://m4.aimg.sk/forig/f_446323455_b6d0be6f4e6a42bd7468df6caab40459.jpg)
-
face flipping t
XD
great patience man.
I remember the story about a photographer, her notebook with all shots was stolen, then returned by police,
but the hard drive was overwritten already. She restored data, but photos were messed up.
Messed up in such beautiful way she made an exposition of them and named after the thief.
-
Looks great, really nice work on that Truck! :)
Marko
-
I have found face flipping WHEN DRIVING to be associated with the upper limits of the suspension. If it hits things freak. If it flips sitting still you have bigger problems.
-
Was just a model face-defining problem whyle i worked on it, no such thing as flipping in OT yet ... at the same time, the space for the wheels is enormous, they would have to break in three pieces, till they hit something around them. :)
... still you have bigger problems.
And i indeed have ... scripting. I cant figure out, why my wheels standing dull (no rotation, only z axis movement), hope it isnt some Blender origin tragedy work (have not a good idea of how this newer one handles them and their individual sub-coordinate systems) ... still, have some things still to try ... but i would really need some help figuring out how to get the complex suspension to work later on ...
... would be grateful, if i could define two bones fixed to certain places on two other meshes acting on them. Then i just could leave the z axis suspension, whyle the wheel axis would just lean according to both wheel center points. (the reality inconsistency of this approach would actually not be much visible) - have to find that post whyte the nicely suspended buggy on the forum. I hope you know witch i mean Zeos. :)
At the same time, the angle-multiplication, by witch other wheels turn around Z axis whyle steering is known from your tatra, but is there a way to define such for one of the front wheels separately ? In realz the ural turns just the left wheel directly, then there is a separate rod going on the xy plane connected to both, where the result is, that at the max position, left wheel is in 45 deg. and the right trough the rod 30 deg. (vice versa for steering in the other direction) - but there is the problem, that if i get the right wheel animated just like an object (like the rods) , interactions are problematic and it probably wont get to help whyte steering at all. So i planned to give the right wheel a angle multiplicand and just define a two-bone connection for the rod to both wheels ...
(http://img.photobucket.com/albums/v245/Oyvind_81/Ural%206x6/2011-10-30112237.jpg) - - - - - the same principle and set-up actually.
The engine filters (later on some more things) should be selectable for each person likings from the import menu - whats the script for your tatra to hide the back-section ? Just giving in the "spavning" instance of the scripting js-file the mesh-false option ? So there is another script to define, there are 2 or three types of such variables for the importer menu ?
P.S. : and yes, its just the bold ural model ... i just wont to get it work properly, till i get to face-flip the grad system, so there is still that killing job to finish. :D ... and sorry that i will start to ask so intensively about everything from now on. Wont to get it into my blood for the future. :)
-
And i indeed have ... scripting. I cant figure out, why my wheels standing dull (no rotation, only z axis movement), hope it isnt some Blender origin tragedy work (have not a good idea of how this newer one handles them and their individual sub-coordinate systems) ...
Heh ... seems i had the wheel mesh pivots in opposite direction - interesting that OT didnt animate them at all like that - now is working corectly.
At the same time, the angle-multiplication, by witch other wheels turn around Z axis whyle steering is known from your tatra, but is there a way to define such for one of the front wheels separately ? In realz the ural turns just the left wheel directly ....
.. heh, i tend to be blind as hell when it comes to scripts - didnt see the new tatra handles things that way - solved. Still the rod and axis has to be bound to them in some way ...
-
Will diferent lerps for each wheel help in case you want them to rotate differently?
Havent done scripting in a while :-X
-
Will diferent lerps for each wheel help in case you want them to rotate differently?
Havent done scripting in a while :-X
... may be ... have to try.
And i need to find out how to stop rotation of a mesh bound to the wheel (the wheel is parent to its inter-section whyte connections to the steering rods and axis - i bound it this way, so it would Z-rotate like the wheel itself, now i have to someway, just for the inner section, limit rotations only to z axis (so it doesnt spin like the tire in ZY plane))
-
Will diferent lerps for each wheel help in case you want them to rotate differently?
Havent done scripting in a while :-X
... may be ... have to try.
And i need to find out how to stop rotation of a mesh bound to the wheel (the wheel is parent to its inter-section whyte connections to the steering rods and axis - i bound it this way, so it would Z-rotate like the wheel itself, now i have to someway, just for the inner section, limit rotations only to z axis (so it doesnt spin like the tire in ZY plane))
Wait.. what? I dont understand why wheel is parent and not vise versa. Ok anyway if it's help try to parents that rod to something else and just copy z values from wheel directly.
-
Will diferent lerps for each wheel help in case you want them to rotate differently?
Havent done scripting in a while :-X
... may be ... have to try.
And i need to find out how to stop rotation of a mesh bound to the wheel (the wheel is parent to its inter-section whyte connections to the steering rods and axis - i bound it this way, so it would Z-rotate like the wheel itself, now i have to someway, just for the inner section, limit rotations only to z axis (so it doesnt spin like the tire in ZY plane))
Wait.. what? I dont understand why wheel is parent and not vise versa. Ok anyway if it's help try to parents that rod to something else and just copy z values from wheel directly.
... there are more ways to set it ... just experimenting ...
Hawe to do a research in such in-time scripts.
-
Two beasts chiling in sunset. :D
(http://m4.aimg.sk/forig/f_446534483_9c1e65cc4206815602ffb4c0bb96c941.jpg)
... will try give them here by the next week, just want at least some pedals be working. (The least i can, before getting the suspension right.)
-
They look quality. You should post some video of them driving around.
-
WoW very nice model, well done PytonPago
-
They look quality. You should post some video of them driving around.
Not yet ... need to tease you guys till some fancy stuff moves on them. ;D ... no need to worry. I just try to make some modifications to the BellAir (i hope, no one gets angry for that ???) vehicle script. Will try to make the gear rod move at each gear change in some way. If i just can ask someone, how do i get the actual wheel RPM from a certain wheel ? (mean some script to get it) At the same time, i want to figure out, how to make the spawn menu to spawn some number of modified versions of the ural (now just two separate imports in the photo), each whyte the weight according to it (if there is(or isnt) a back-section, or the grad unit).
Progress is a little slow in the end, i had to figure out the pivot point system of blender and now i do with each script a change to the needed parts and parentings. Is a little time-consuming thing and i had not much to play with it the last weeks. Stay tuned for more ... there will be some. :)
-
Annouce alpha for testing out ... see :
http://www.outerra.com/forum/index.php?topic=2095.0 (http://www.outerra.com/forum/index.php?topic=2095.0)
-
Had implemented the Grad into OT. That FPS drop - just glorious ! ;D Not finished yet doe, still need to do the arm-targeting system and some details (electro station and signalizations and the rocket itself).
(http://m4.aimg.sk/forig/f_447133279_713cb3615ce2f4b89b192e3b0b049a22.jpg)
(http://m3.aimg.sk/forig/f_447133274_ce4fd3f4ccdb0c29b69d47c3679e62d9.jpg)
(http://m3.aimg.sk/forig/f_447133270_13c27d9d7b5f2410d10d53e59b2f6a42.jpg)
-
Thats cool!
-
Got an idea : ... when the force app gets its way, why not hawing and pre-defined script of some kind ?
Force ("mesh bone" , "force strenght in number value" , x:0, Y:1, z:0,)
Being able to just write into the vehicle and aircraft scripts would make it easy to make recoils.
-
Great looking model! Nice work. :)
Marko
-
FIRE!
-
Had implemented the Grad into OT. That FPS drop - just glorious ! ;D
Did you actually had an FPS drop? :-\
-
I'm hoping he means the lack of it. ??
-
Wait till i post the grad unit ... you will see when you give 5 of those on the ground ...
-
Wait till i post the grad unit ... you will see when you give 5 of those on the ground ... not much of a machine mine here, but still was a real great drop.
-
We don't know what you mean by a "great drop."
-
We don't know what you mean by a "great drop."
§
like 6-13 FPS ;D it really needs other LODs done afterwards ...
-
Is that how much you lost or how much you got down to?
-
Is that how much you lost or how much you got down to?
.. got down to that number ...
-
Um... That's not a good thing. ? :-\
-
Um... That's not a good thing. ? :-\
.. its a raw model ... that means other stuff will make it a hell when implemented, like textures (all types) added weather, lightning and smoke. If there will be a full battery (15 of them). Well, it will not be the only thing in the game. :-\ How do the LODs work ? ... will separate model parts switch them or will the complete model be switched at once ? If the separate part way works, it would be good, could script some parts to lower LOD while in firing mode (those witch will be cowered by smoke) for the needed time.
-
Arent the LODs made by the engine itself?
-
Arent the LODs made by the engine itself?
You still can pre-define them in the model - if you make it in such hierarchy as it should, it takes them ...
-
Intereseting... Makes me think if adoptive tesselation could be adopted...
-
Intereseting... Makes me think if adoptive tesselation could be adopted...
... well, why not ... i just wait for more action-buttons for vehicles from cameny at this time, but im pretty sure it comes after they get all things finished on the plan list before rigid axiles. So im playing around whyte scripts. Doe, if there would be a simple way to in-script add, or further extend the existing - lets just say to use the O button, but certain actions will happen only if another key (in vehicle script further defined) would be pressed at the same time ...
-
Hallo there !
This one will be mainly for cameny : i just tried to add two functions to my vehicle and i cornered myself at a corner of a syntax thing and an problem i was not aware of before. But first the actual script :
http://www.upnito.sk/subor/91e3f56054e9dc9db1c79bb9b9b3fac5.html (http://www.upnito.sk/subor/91e3f56054e9dc9db1c79bb9b9b3fac5.html)
The thing begins at the "function action" (294 line) part. How do i give the vehicle two different functions (AOpen and ATurretX/Y) when the definition of them is the same ?
I mean if there must be : function action (---, ===, dt) for both (and adding other variables is irelevant as he uses only the first two ones towards dt), the second is taken as the only true thing he will do ... so how can i use both at the same time ? (will add lights and shiftUP/DOWN for door-windows later so i need it to work together)
P.S.: Dont mind the RPM Needle at the end - is thought for my engine mod., but not finished yet.
-
We don't know what you mean by a "great drop."
§
like 6-13 FPS ;D it really needs other LODs done afterwards ...
That model looks very geometry heavy- Why not let textures add some of the detail instead?
-
The thing begins at the "function action" (294 line) part. How do i give the vehicle two different functions (AOpen and ATurretX/Y) when the definition of them is the same ?
I mean if there must be : function action (---, ===, dt) for both (and adding other variables is irelevant as he uses only the first two ones towards dt), the second is taken as the only true thing he will do ... so how can i use both at the same time ? (will add lights and shiftUP/DOWN for door-windows later so i need it to work together)
You must have just a single action function, and handle all keys in there. Like this:
function action(k,v,dt)
{
switch(k){
case ATurretX: this.geom.rotate_joint_orig(turret, v, {x:0,y:0,z:-1}); break;
case ATurretY: this.geom.rotate_joint_orig(mantlet, radians(TurretAngleSpan*0.5*(1+v)+MinTurretAngle), {x:1,y:0,z:0}); break;
case AOpen: {
if(value == 1 && aOpenBool == true) {
....
break;
}
case ....
}
Or you can use chained if statements instead of the switch.
-
so the "case ... break" separates them from each other, but time depending variables must stay just the k,v, (or whatever i choose) ?
-
The action() is invoked for each action separately, with different k and v (you can name the parameters as you wish). You handle it depending on the action type. If you need to keep some state variables for some actions, just attach them to "this". Usually, you want the actions to start/stop a movement. There's a helper class included that will automatically handle the position integration, axis_integrator, usually used for turrets but also other things:
function radians(v){return v*Math.PI/180.0}
//axis integrator takes max speed and acceleration values, optionally min/max clamp values
function init_vehicle(){
this.turx = new axis_integrator(radians(MaxTurretXSpeed), radians(MaxTurretXAccel));
this.tury = new axis_integrator(radians(MaxTurretYSpeed), radians(MaxTurretYAccel), radians(MinTurretAngle), radians(MaxTurretAngle));
this.turretsnd = 0;
}
function action(k,v,dt)
{
switch(k){
case ATurretX: this.turx.set(v); break; //pass value from the action to the integrator
case ATurretY: this.tury.set(v); break;
}
}
function update_frame(dt, engine, brake, steering)
{
//turret handling, changed(dt) returns true if the axis_integrator value changed
var tmov=false;
if(this.turx.changed(dt)){
this.geom.rotate_joint_orig(turret, this.turx.value, {x:0,y:0,z:-1});
tmov = true;
}
if(this.tury.changed(dt)){
this.geom.rotate_joint_orig(mantlet, this.tury.value, {x:1,y:0,z:0});
tmov = true;
}
//play turret sound while it moves
if(tmov) {
if(!this.turretsnd)
this.snd.play_loop(1, 3);
}
else this.snd.stop(1);
this.turretsnd = tmov;
-
AWW !!! Now i got it ! Thanks a LOT Cameni ! Been working on this three days and was depressed as a mosquito on synthetic blood. Here is my way of doing it for all people to see :
//handle extra actions
function action(k,v,dt)
{
switch(k){
case ATurretX: this.turx.set(v); break;
case ATurretY: this.tury.set(v); break;
//this.log_inf("aOpenBool " + aOpenBool);
// Hood oppening
case AOpen: {
if (v == 1 && aOpenBool == true) {
this.geom.rotate_joint_orig(this.cc, 0, {x:1,y:0,z:0});
}
if (v == 1 && aOpenBool == false) {
aOpenTime = aOpenTime + (2 * 1);
this.log_inf("aOpenBool " + aOpenTime);
this.geom.rotate_joint_orig(this.cc, 1.75, {x:1,y:0,z:0});
}
if (v == 1) {
if (aOpenBool == false) {aOpenBool = true;}
else{aOpenBool = false;}
}
}break;
}
}
Actually just needed to change the "value" for "v" everywhere and giving all the stuff into - "case AOpen: { ... }break;" . So simple and so much hair lost till today ! :D Other question doe:
- headlights-script, its just added there, but light-sources not yet done in OT, is that right ? (well, if i dont do that the Billboard (texture) way at least for the bulbs), anyway will try to add some honk-honk sound, finally some fun stuff into my model !
- Is there a way to fix some of the views to a certain mesh ? I mean, if i will change the second-view position to be at the BM-21 targeting arm and i rotate it around, i will just stay at there whyte the camera, whyle the ocular goes away from me. I would like to change that position in accordance to the mesh im rotating. Maybe just make an addition to the action codes or somewhere else to define the mesh i chose and the camera position will update every image around its pivot whyte the mesh (maybe even have the "x:0, y:1, z:1" to determine, witch rotations from the mesh-rotation it should apply to the camera). I can think of a way of scripting this into the vehicle-script, but i think more people would like to use this (mostly mil-simmers find it useful).
So could be there the force app added to the scripts too later in some nice way ? ("AFire: this.geom.force_joint_orig ("mesh", "force strength", {x:0.87, y:0.25, z:0.64} - to define the force vector from the mesh-pivot point)")
P.S.: Sorry for pushing so much for new apps. : )
-
Gave up my little progress up in the Ural 4320-31 thread to download and try ... i took Murkz´s Luchs sound for the turret. Hope he does not kill me for that. ::)
-
- Is there a way to fix some of the views to a certain mesh ? I mean, if i will change the second-view position to be at the BM-21 targeting arm and i rotate it around, i will just stay at there whyte the camera, whyle the ocular goes away from me. I would like to change that position in accordance to the mesh im rotating. Maybe just make an addition to the action codes or somewhere else to define the mesh i chose and the camera position will update every image around its pivot whyte the mesh (maybe even have the "x:0, y:1, z:1" to determine, witch rotations from the mesh-rotation it should apply to the camera). I can think of a way of scripting this into the vehicle-script, but i think more people would like to use this (mostly mil-simmers find it useful).
This will come later, a way to attach camera points to model nodes.
So could be there the force app added to the scripts too later in some nice way ? ("AFire: this.geom.force_joint_orig ("mesh", "force strength", {x:0.87, y:0.25, z:0.64} - to define the force vector from the mesh-pivot point)")
Force? I don't know what you mean, what do you want to achieve?
-
So could be there the force app added to the scripts too later in some nice way ? ("AFire: this.geom.force_joint_orig ("mesh", "force strength", {x:0.87, y:0.25, z:0.64} - to define the force vector from the mesh-pivot point)")
Force? I don't know what you mean, what do you want to achieve?
The force app witch we discussed much earlier ... where talking about an analog to the crater-creator, just giving some force-push to the objects. I thought it would be interesting if at fire, the vehicle would not use some animation for the back-kick of rockets, but a real force ... just old debate stuff thoughts. Dont have to mind that one. ;)
-
That's going to be a part of the projectile firing system, automatically exerting kickback force at the point from where it was fired.
But there's also a way to produce arbitrary forces, for example in the upcoming support for boats the propelling is done as an extra force.
-
... for example in the upcoming support for boats the propelling is done as an extra force.
Sounds nice ... the water will have some water-wolume-based counter forces to the boats ?
-
Yes, computed from provided approximate volume shape. Boats are technically ground vehicles, just with extra params. You can easily make an amphibious vehicle too.
-
Sound really good! Will the same parameters apply for hand-held guns as well?
Also, how will sails work in ships?
-
Sound really good! Will the same parameters apply for hand-held guns as well?
It may, but it would require a proper character animation or IK.
Also, how will sails work in ships?
I guess .. one can compute the forces from wind and area and orientation and just apply them.
Plus some animations ...
-
You can easily make an amphibious vehicle too.
Well, have to start making a BTR-80 for testing when it comes. :D
-
Got a question about : http://xtrac.outerraworld.com/trac.fcgi/wiki/geomob (http://xtrac.outerraworld.com/trac.fcgi/wiki/geomob)
- i want to turn certain parts invisible and just cant find out, where to put the scripts .. as i understood from the Sh-2 script, the "set_mesh_visible_id" should be at "function update_frame" section, and "get_mesh_id" at the "init_chasis" part (when given to "init_vehicle", he cant get it and says it hast the geometry defined), bud doesnt work straight at that .. do i have to define some variable (the mesh itself) ? I tried it like the shavrov has whyte some id variables set, but no real thing happens.
-
get_mesh_id can be anywhere, but it's usually in init_chassis because you need to get the id of mesh just once, and then you store it in a global variable. Then you can use the id with functions that take mesh id as argument, usually in update_frame or in action.
-
... and then you store it in a global variable.
So something like :
...
var mklt
mklt = geom.get_mesh_id('mesh_name'); // (doesnt it need the gemetry joint mentioned too ?)
...
and then in update_frame section:
if (something) {
geom.set_mesh_visible_id(mklt, true);
}
else {
geom.set_mesh_visible_id(mklt, false);
}
-
I found out why it didnt work ... too much "geomob´s ()" had to rearrange it so, that they dont interfere. Now trying to work out the wheel damage system somehow, anyway there is one little thing i would like to do too - as per my script :
steering *= 0.4; // defines steering constant for wheels
this.steer(0, steering); // defines witch wheel is turning, and witch script it uses
this.steer(1, steering);
this.geom.rotate_joint_orig(this.IntFL, steering, {x:0,y:0,z:1}); //rotation restriction for the internal front wheel part
this.geom.rotate_joint_orig(this.IntFR, steering, {x:0,y:0,z:1});
... i have a wheel composing of the wheel and its internal part (of two components too ... see pics down the reply) and scripted the z axis turning of the internal part as the wheel does. Now i would like to add to it its height according to the wheel.
- Is there a way to get the actual deviation from its original position for me to implement it to the internal part ?
- Or some way to limit the movement of some axis (actually just the x axe rotation) of a part under the wheel hierarchy ?
Another interesting thing :
I was giving the hidding-script a test and i scripted it like this :
case AOpen: {
//this.log_inf("aOpenBool " + aOpenBool);
// for hidding wheel emptyes of the wheel-change script
//FL
if (v == 1 && aOpenBool == true) {
this.geom.set_mesh_visible_id(this.fl_id, true);
this.geom.set_mesh_visible_id(this.fle_id, false);
}
if (v == 1 && aOpenBool == false) {
aOpenTime = aOpenTime + (2 * 1);
this.log_inf("aOpenBool " + aOpenTime);
this.geom.set_mesh_visible_id(this.fl_id, false);
this.geom.set_mesh_visible_id(this.fle_id, true);
}
...
So the whole wheel should hide and the internal part appear, but even when there is just three parts :
(http://m4.aimg.sk/forig/f_448785843_7a30e8efe399f57b2332b8e38f2c45ac.png)
... the middle part of the wheel yet still is there ? (Wheel_FrontR)
(http://m1.aimg.sk/forig/f_448785856_b45c1f0d0d5605b04c152cf1295bd124.png)
I know that i done the wheel by making the inner part and the wheel resin separately (both whyte an separate material), but joined them into one mesh (nothing stays behind in a separate mesh), so there is no reason to be left behind, yet, still it does ... so, is it possible, that the fact, that the inner part has an other material than the resin wheel makes it to ignore in script ? - leaving it behind (means rendering one of the materials anyway) ?
-
Just done a test ... left wheel got one material and the other the second ... both dissipated completely, but the other ones, composing of two materials still leave one there ...
(http://m4.aimg.sk/forig/f_448786695_0a95d96141ed488f75756d4dc2286dcc.png)
second test - have stripe-materialed the mesh of the wheel:
(http://m1.aimg.sk/forig/f_448786976_d3cc70e78931c96c715df85065842beb.png)
... seems it has a problem whyte hiding multiple-material meshes.
-
... i have a wheel composing of the wheel and its internal part (of two components too ... see pics down the reply) and scripted the z axis turning of the internal part as the wheel does. Now i would like to add to it its height according to the wheel.
- Is there a way to get the actual deviation from its original position for me to implement it to the internal part ?
- Or some way to limit the movement of some axis (actually just the x axe rotation) of a part under the wheel hierarchy ?
The wheel() function returns run time wheel & suspension data http://xtrac.outerraworld.com/trac.fcgi/wiki/wheel_data (http://xtrac.outerraworld.com/trac.fcgi/wiki/wheel_data)
... the middle part of the wheel yet still is there ? (Wheel_FrontR)
I know that i done the wheel by making the inner part and the wheel resin separately (both whyte an separate material), but joined them into one mesh (nothing stays behind in a separate mesh), so there is no reason to be left behind, yet, still it does ... so, is it possible, that the fact, that the inner part has an other material than the resin wheel makes it to ignore in script ? - leaving it behind (means rendering one of the materials anyway) ?
Multi-material meshes are internally separate meshes, and I think there was a problem with the function affecting only the first mesh with given name.
-
The wheel() function returns run time wheel & suspension data http://xtrac.outerraworld.com/trac.fcgi/wiki/wheel_data (http://xtrac.outerraworld.com/trac.fcgi/wiki/wheel_data)
wow .. how did i oversee this page ?
-
Multi-material meshes are internally separate meshes, and I think there was a problem with the function affecting only the first mesh with given name.
So the importer makes all those meshes split into more meshes, will you try to do it work ? .. or maybe there would be a way to extract the second one to add another line for that one ... hmm .. most probably i have to separate it.
-
... made my wheels separate ... now working on wheel-change script, doe one problem is there - i may not use variables well. My script base is like this :
// Variations of wheelparameters for the wheel-change function
// Variations FL
var wpflg =
{
radius: 0.60, //<-- edit this to 0.3 (remember our wheel radius of 30cm!)
width: 0.25, //<-- edit this to 0.2 (this represents the height parameter in 3d max of 20cm!)
suspension_max: 0.27,
suspension_min: -0.21,
suspension_stiffness: 25,
damping_compression: 0.08,
damping_relaxation: 0.07,
slip: 2.0, //0.8
slip_lateral_coef: 0.98, //0.955
roll_influence: 0.1,
rotation: -1.0
};
var wpfld =
{
radius: 0.30, //<-- edit this to 0.3 (remember our wheel radius of 30cm!)
width: 0.25, //<-- edit this to 0.2 (this represents the height parameter in 3d max of 20cm!)
suspension_max: 0.27,
suspension_min: -0.21,
suspension_stiffness: 25,
damping_compression: 0.08,
damping_relaxation: 0.07,
slip: 3.0, //0.8
slip_lateral_coef: 0.65, //0.955
roll_influence: 0.01,
rotation: -1.0
};
.................................
// End of variations for the wheel-change script
//Wheel-change script
//INFO: This script changes the wheelparameters for the individual wheels based on "..."situation witch says if its good, damaged or not there at all.
// 1 - good condition 2 - baad condition 3 - not there
// FL
const wpflsituation = wpflsitvar
if (wpflsituation == 1) {wpfl = wpflg}
else{wpfl = wpfld}
.................
//handle extra actions
function action(k,v,dt)
{
switch(k){
case AOpen: {
//this.log_inf("aOpenBool " + aOpenBool);
//Wheel-change script wisible mesh and param part
if (v == 1 && aOpenBool == true) {
wpflsitvar == 2
this.geom.set_mesh_visible_id(this.fl_id, true);
this.geom.set_mesh_visible_id(this.fle_id, true);
this.geom.set_mesh_visible_id(this.flg_id, false);
this.geom.set_mesh_visible_id(this.fld_id, true);
}
if (v == 1 && aOpenBool == false) {
aOpenTime = aOpenTime + (2 * 1);
this.log_inf("aOpenBool " + aOpenTime);
wpflsitvar == 1
this.geom.set_mesh_visible_id(this.fl_id, true);
this.geom.set_mesh_visible_id(this.fle_id, false);
this.geom.set_mesh_visible_id(this.flg_id, true);
this.geom.set_mesh_visible_id(this.fld_id, false);
}
if (v == 1) {
if (aOpenBool == false) {aOpenBool = true;}
else{aOpenBool = false;}
}
}break;
}
}
So i actually want to change the "wpflsitvar" by hitting O (to try if the wpflsitvar based script itself works) but it just changes the visible meshes, not the "wpflsitvar" to 1 or 2. I tried to put it all over the place and still, somehow it just identifies the value as first mentioned in the script file (as you see, its 2), newer making any difference. (tried too an basic if script in the "function update_frame" section - still changing just the mesh visibility, not the "wpflsitvar" value) can you see, where i do something bad ?
Whole script : http://dl1.upnito.sk/download.php?dwToken=9fb7f52f615ddbdeb01e963979046ca8 (http://dl1.upnito.sk/download.php?dwToken=9fb7f52f615ddbdeb01e963979046ca8)
I want to make later the "wpflsitvar" value change when the z axis position of the wheel hits its max. so that the wheel geds damaged and changes its defining values whyte it ...
-
Uff what construct is this:
wpflsitvar == 1
this.geom.set_mesh_visible_id(this.fl_id, true);
this.geom.set_mesh_visible_id(this.fle_id, false);
this.geom.set_mesh_visible_id(this.flg_id, true);
this.geom.set_mesh_visible_id(this.fld_id, false);
Probably should be assignment (=), not comparison (==).
-
Uff what construct is this:
wpflsitvar == 1
this.geom.set_mesh_visible_id(this.fl_id, true);
this.geom.set_mesh_visible_id(this.fle_id, false);
this.geom.set_mesh_visible_id(this.flg_id, true);
this.geom.set_mesh_visible_id(this.fld_id, false);
... just a leftover from copy-paste too much ... doe changed to = does not still has the changing effect there ... is there a problem it being after these lines ? ::::
...
// BR
const wpbrsituation = wpbrsitvar
if (wpbrsituation = 1) {wpbr = wpbrg}
else{wpbr = wpbrd}
this.add_wheel('Wheel_FrontL', wpfl); //<-- the name "wheel_FR" is the name you used for your wheel mesh in 3d program
this.add_wheel('Wheel_FrontR', wpfr);
this.add_wheel('Wheel_MiddleL', wpml);
this.add_wheel('Wheel_MiddleR', wpmr);
this.add_wheel('Wheel_BackL', wpbl);
this.add_wheel('Wheel_BackR', wpbr);
Probably should be assignment (=), not comparison (==).
-
You wrote:
So i actually want to change the "wpflsitvar" by hitting O (to try if the wpflsitvar based script itself works) but it just changes the visible meshes, not the "wpflsitvar" to 1 or 2.
That was because you weren't assigning it.
Now changing the wheel parameters this way won't work. Existence of wheels doesn't depend on the visibility of meshes, wheels actually have no idea which meshes pertain to them.
This requires a support for disabling the wheels at run time.
-
You wrote:
So i actually want to change the "wpflsitvar" by hitting O (to try if the wpflsitvar based script itself works) but it just changes the visible meshes, not the "wpflsitvar" to 1 or 2.
That was because you weren't assigning it.
Now changing the wheel parameters this way won't work. Existence of wheels doesn't depend on the visibility of meshes, wheels actually have no idea which meshes pertain to them.
This requires a support for disabling the wheels at run time.
.. nah, the visibility of meshes where there just to check on the actuall AOpen script work verification and add onto it, didnt want to do that in an separate script ..
I just wondered why the wheel-parameters would not update as it is made as an variable (- wpflg(good wheel) and wpfld(damaged wheel) being assigned trough wpflsituation (in the if before "this.add_wheel"´s) hawing value according to wpflsitvar (1 or 2) --- ) depending on the AOpen given state (wpflsitvar (= 1 or = 2)).
I know i could skip one of them, but it will be needed for further development of the wheel changing (other dependencies and events added onto it later).
so you say the "this.add_wheel('Wheel_FrontR', wpfr);"´s wpfr cant be an changing variable yet ?
-
When you call this.add_wheel(...), the call goes through the API and the JS object (wpfr) gets streamed on the C++ side into a corresponding C++ object, and handled by the appropriate class. There's no connection between the two after that conversion.
-
When you call this.add_wheel(...), the call goes through the API and the JS object (wpfr) gets streamed on the C++ side into a corresponding C++ object, and handled by the appropriate class. There's no connection between the two after that conversion.
... well that stops my work on the wheel-changing for now. :P Well, seems that i will have to figure out the engine-pimp first then. Thanks anyway cameni, im some new stuff brighter now.
-
Since now in school, started to work on the rest-details to the model and on the rockets themselves. First one the shrapnel warhead M-210F/9M22U ( М-210Ф/9М22У in russian lettering ). This one is actually the most simple, no dispatching parts, just a ballistic projectile, but coming mining and cassette-load warheads will be done whyte internals to have them dispatch in flight and work as they should.
(http://m1.aimg.sk/forig/f_449527256_9cb3f00c7e66045f581296bbfc8458a1.png)
... and on the BM-21 whyte the detail of the rocket-exhaust cower :
(http://m4.aimg.sk/forig/f_449527271_e3cc4c1a9a70d59780912c8217105882.png)
(http://m4.aimg.sk/forig/f_449527279_ad4e0a9efcebd525ee924aed88668311.png)
Will have to modify the flat Ural too, to make the support rearming vehicle:
(http://www.dishmodels.ru/picture/wlk/02/02319/w02319_1561005.jpg)
-
Keep them comming. You`ll be the pioneer rocket scientist here in Outerra once rockets are implemented!
-
Keep them comming. You`ll be the pioneer rocket scientist here in Outerra once rockets are implemented!
... nah, we need some russian OKB´s or NASA (oh no, their now stopped due to funding problems from WH ) for that stuff. :D
Doe, making an pyrotech. sim whyte all those vehicles and stuff - that would be an interesting thing for me as a chemist. ???
Anyway, i just want to do those, because their ballistics are a little enhanced compared to classical mortars/cannons. And if the different munition types and parachute-AT-modules get working, it will be a classy showoff in OT. (not to mention that big-artillery guns have such tech-stuffed munitions too, so some special cannons would be a easy thing to do, once it gets there). -- And : whyte that much of space, its basically a sin not to try far reaching artillery. Especially when the multilayer comes out. Mark my words ! :D
-
Those whitewalls.
-
Those whitewalls.
In soviet times, they has some paint-classification for different batteries. But nowadays all of them are different lenght, so they dont do much painting anymore (except off-broad exported ones)...
(http://rbase.new-factoria.ru/sites/default/files/gallery/s.gurov/12/10/23/img_9211.jpg)
...still have the lettering, so no problems identifying for the army-men.
(http://rbase.new-factoria.ru/sites/default/files/missile/s.gurov/Russia/Grad-1/9m28d_1.jpg)
(and im lazy to go into textures now :D May wait till OT´s expert is free for another project :) )
... will have to look into the lettering too, so i dont make a mistake there whyte new ordnances. :-\
-
Hmm ... just found a little nerve-breaking problem - since the importer "makes different meshes due to materials", i gonna have a little problem whyte rockets in the launcher. There are around 9 types of rockets available for it, so:
- i have to make each of those rockets at each place of the launcher pods if i will have the difference visible in the launcher itself.
- make each material part of each rocket a different mesh and so a part-multiplied script for making the meshes visible/invisible for them. (yes, making them all one-material based whyte texture would simplify the work, but there is an else reason for witch i do it this multiple-material way)
Will likely need to make some external indexing-file for the pylons so i dont have to do complex IF´s in vehicle script, just an link to the file ... that will take some learning. :-\
Project starts to be really challenging. :D
P.S.: memo for modders and model makers - do not try to make varial munition open-pylon rocket launchers of complex structural integrity. :)
-
Just speculated whyte the extra_force a little and found somewhat of a possible little problem. For ship movements (and analogs (rockets and space ships in near zero gravity)) its fairly well that the value for steering (in x axis) can be zero and its intensity growing from it in both + and -. Doe this approach can prove a difficult thing for weapon systems, or rotational ship propulsion systems, where it would be better fixed to a certain mesh origin(pivot) - so the impulse would be a constant, vector according to the origin(pivot) and the actual change of the direction would be done just by rotating the mesh, to witch it is bound.
An example white my grad - rotation is defined by the turret-script, where the rotation is defined trough the this.turx.value and this.tury.value, witch at spawn has a 0 value. So if i will the fire back-force act in the right direction, i have to :
this.extra_force({x:0, y:-3, z:2.4},{x:-40000*this.turx.value, y:-70000*this.tury.value, z:0});
(i defined the place, where the force acts to the approximate position of the grad system on the vehicle)
so if its in basic position, then the vector is zero, what means no force being applied. In my case its OK, cause the grad has a backwards oriented amortizator (rear hydraulic wheel axile suspension fixing device). But in some stationary weapon systems would be (a tanks cannon) such behaving a little odd. At the same time, the vector "length" (thus the force power) is not a constant value too, witch may for such kinds of applications be a bad thing, if it should stay constant ...
Changing the actual extra_force script would be bad, its behavior has its good sites, so if there could be another such force-type script added, but whyte mesh-origin(pivot) vector orientation base, it would be a nice and useful addition.
-
There can be an extra_force variant that takes a joint id as the argument, and the two vectors can then operate in the joint/bone space instead. You can achieve the same behavior by rotating the vectors using bone quaternion, but that's clumsy to do in Javascript without quaternion math lib.
-
There can be an extra_force variant that takes a joint id as the argument, and the two vectors can then operate in the joint/bone space instead.
;)
You can achieve the same behavior by rotating the vectors using bone quaternion, but that's clumsy to do in Javascript without quaternion math lib.
Hmm .. have to look into that way.
-
(http://m4.aimg.sk/forig/f_450827727_1cfb8e1c94e609b371e51921606753a4.png)
Just thought of a little challenge ... till some other things can go from where i am. Im very interested how the interior will come out ... and what OT says to it. :D
(http://army.lv/large-photos/btr-80.35501.jpg)
-
Just thought of a little challenge ... till some other things can go from where i am. Im very interested how the interior will come out ... and what OT says to it. :D
I hope better than mine!
Work in progress.
airdefence command point BTR-60 PU-12
(http://i.imgur.com/TB1EjoD.jpg)
(http://i.imgur.com/cdC2WrB.jpg)
-
Wow, that is a nice work there on the equipment pal ! Im planing to get the AK-shooting places a proper use and make the interior as best it can get, doe i dont know if i will take on the engine-compartment. ... there is a lot of variations of the BTR series from command to utility vehicles, would be nice to have a few of them in the future ...
(http://armor.kiev.ua/Tanks/Modern/btr80/btr80_5.gif)
There is a nice publication on the whole series starting from the II world war, its in russian, but there is a lot of interesting photo-documentation inside too:
http://bookre.org/reader?file=539617&pg=2 (http://bookre.org/reader?file=539617&pg=2)
A little odd doe, that it isnt one of the machines white a higher placed roof, must have been very small operation space in there.
You planing the 60-ty for some AA defence sim ? Know there was some talk about such a thing in OT a longer while ago, would be nice to see it go on.
-
A little odd doe, that it isnt one of the machines white a higher placed roof, must have been very small operation space in there.
You planing the 60-ty for some AA defence sim ? Know there was some talk about such a thing in OT a longer while ago, would be nice to see it go on.
Thanks!
Most soviet vehicles are quite cramped. (especially BMD's, tanks)
In spare time as hobby i model 3d cabins/exteriors of air defense units.
While i'm not planing to create air defence sim, who knows maybe such team will gather and create something. :)
But first lets wait for SDK.
As right now i have:
ZSU-23 (exterior + interior)
SA-13 (exterior + interior)
SA-8 (exterior + interior)
PU-12 (exterior + interior)
S-300PS 30N6 (interior)
ST-68U (interior)
Roland MAN 8x8 (exterior + interior)
Patriot PAC-2 (interior)
*These models require mesh refurbish + texture work.
-
Wow ... that is some nice info! You just made me want to see all of them. :D I would certainly like to see the Shilka and Strela-10, not to mention all of them in OT, we hawe to put them models to some use ! ;D
Most soviet vehicles are quite cramped. (especially BMD's, tanks)
Yes, the soviet approach was on low profile vehicles to be a harder target for manual aiming back then. Now such things start to become obsolete. Doe whyte the new IL-79 it might come back just for airborne sakes.
They did build a lot of modded versions of them (even of the older BMD series) for all the non-combat army brigades and civil use.
(http://www.ausairpower.net/PVO-SV/PU-12-M7-CP-MAKS-2009-VVK-1S.jpg)
(PU-12M7)
(http://carphotos.cardomain.com/ride_images/3/1914/2241/29783620010_large.jpg)
(Volga GAZ-21 - that would be a nice mobile camping-house)
P.S.: Just mentioned in that model, that the internal space is actually to the end of the back-roof door. How to hell did they manage back then put two V-6 engines and a water-turbine in the remaining space when the modern 80 has 1/3 of the space for them (just like the modern PU in photo) ? ;D
-
Uff ... details, details, details ... they will be the death of me. ;D
(http://m3.aimg.sk/forig/f_451058110_d49b5e1be883e6b766ca2912eec8cbef.png)
-
Pfft. That looks like ass pyton.. You didn't even model each individual rivet.. individually.
-
Pfft. That looks like ass pyton.. You didn't even model each individual rivet.. individually.
Damn you Zeos !!! If your comment makes me "model each individual rivet.. individually", im gonna finish that model when my beard is like Gandalfs ... and make you wear a sweater made out of it !!! :D
-
I'm trying to get into modeling, but it seems I can't get past modeling car hoods. Should I be using Turbo Smooth (3ds max)?
-
I'm trying to get into modeling, but it seems I can't get past modeling car hoods. Should I be using Turbo Smooth (3ds max)?
Best is to make a very simple mesh of it just by a lightly subdivided plane. Then, when its done, you do a subdivide and smooth combination till its in your desired state. Doe, every smooth curve must be done by a two or three angle steps. (if you do just an single angle and the plane is wide, it will smooth it in the median points of the planes, so the curve radius will be wide accordingly, but if the angle consists of two-three narrow planes, medians are very close to each other and so smoothen will result in a nice planed curve) ... there are a lot of such small tips to do at modeling, most of them are even on youtube to find (just type car-modeling 3DMax) and jump trough them. Some might have even other interesting stuff at them -- that was my way of learning stuff at blender, looking at vid. whyle tried out.
Of course, there is even an "stretch" function too, but i dont use it much. (more for character modeling than technical stuff, if there are not much nice curves).
-
How do I subdivide for the smoothing? When I use Inset on a quad it still comes out as circular in TurboSmooth.
Nvm got it.
-
Hmm ... a lot of AKs have to be in such a vehicle shooting windows ... its kind of a interesting problem here, if i make them a part of the vehicle, i would have to compensate the variability of the weapons in each of the window (AK(S)-74M / -47 /AKM /PKM) ... on the other hand if there would be a fixing position defined for the weapons themselves as a separate model, it has to be fitted to the window-grips for them, thus complicating animations and scripts a little ...
(http://77rus.smugmug.com/Military/AMZ-and-GAZ/i-FmvV2dD/0/O/AMZ_47.jpg)
(the circular windows - one of them has an armature for a MG)
(http://m4.aimg.sk/forig/f_452037955_437c157ca0c060752482a426b551aa4e.png)
(http://m1.aimg.sk/forig/f_452037932_9c4b00ba7e0e43d5a8eeb96d469600ad.png)
The size is right compared to the human and Ural. Looks like an sardine-can if you realize how much people should fit in.
(http://m3.aimg.sk/forig/f_452037914_c4dd015f51553c2e3f7c2d1e269f963d.png)
(http://m4.aimg.sk/forig/f_452037887_86e4c87775eb3a5f65792042568feb9b.png)
-
I cant wait to use the wheel animation (as has hrrhrr used on the buggy) on my little "box" (a soviet afghan war term for column vehicles). :D
(http://m1.aimg.sk/forig/f_452227396_03566831b28d118c6efb15b16ba3f54b.png)
-
very very beautiful! very good
-
And the final exterior version of the BTR is there :
(http://m3.aimg.sk/forig/f_452780166_8cebaee00448a704c087361d0a6913b4.png)
(http://m2.aimg.sk/forig/f_452780185_3d99d366e6e5745fb4db10fd09dd343b.png)
(http://m1.aimg.sk/forig/f_452780188_0496e053395ebf982847ced227a6ffcc.png)
(http://m2.aimg.sk/forig/f_452780205_0c11a0147e8104893095002f2e94f23d.png)
And the gunner sight wiew :
(http://m4.aimg.sk/forig/f_452780199_819f5e610d7311fcfde9c226ade2cf76.png)
-
Lovely work, well done PytonPago.
-
Wow. That looks perfect .. Low grass mode is sort of a bummer.
Are you planning to texture the whole thing? It is a bit too shiny the way it is now. Has that showroom shine on it.
-
smooth all these normals :) looks great
-
Now just slap some textures on there. :D
-
nice BTR, Pago. ;)
-
Looks amazing! GJ
-
Wow. That looks perfect .. Low grass mode is sort of a bummer.
i actually newer played whyte grass at all .. also it might be the unusual format of my LCD (isnt 3:4 but more like 21:23 and it makes close things look funny sometimes - like the opt. ilusion effect doe :D )
Are you planning to texture the whole thing? It is a bit too shiny the way it is now. Has that showroom shine on it.
Yes, actually both Ural and BTR, but first i have to do the interior and get a better hold of the UV tool in Blender (have some issues whyte pealing oranges there). You can see the periscopes are missing right now - is much easyer to make them from inside-out. That will take a while. Seems it will come out to annual model-releases form me - await it whole at summer. :D :D Dont worry, i try to script it driving till Silvester.
-
... could there be a possibility to show actual vehicle RPM in addition to the speed in the HUD (if being inside a car) ? Speculating around engine props and at them based scripts, speed indicator is nice to adjust speedometer and other speed related equipment/functions at real time in OT. An actual RPM indication would be a great addition to certain tests and adjustments ...
... also, does Math.sqrt work ? Cant make it work somehow (takes value as undefined). Would need that a lot for an animation.
P.S.:
... started working a litle at the ural interiors as a sidework, Blender to OT UVs application:
(http://m2.aimg.sk/forig/f_453082061_127dd59f7105f1d16ae583107a599f3f.png)
-
Well ... what an nice test outcome - so terrible its actually magnificent :D :D
(http://m1.aimg.sk/forig/f_453146656_f0ac82367099be5dd490bf84c29e310d.jpg)
... are there any limits on how many and how big UVs there can be on an single model (etc. their pixel size) ? Seems i will need to apply a lot of them and the most of them whyte almost all types (normal, env., refl.).
-
This thingy is odd ... 5 textures in all - every one trough multiple objects and there this problem whyte only one of them for all its parts :
(http://m2.aimg.sk/forig/f_455147909_c0e557c3b483a5975acc79bef67f142e.png)
(http://m4.aimg.sk/forig/f_455148755_3f9c157d5e3421275f22fb61b8d0ef44.png)
-
probably you didnt name the vertgroups right ?
i think in blender you have 3 important names first two same name Mesh and Vertgroups and all other textures ?
I recall i had different name for mesh and vert groups (UV) and it gave me same error
Strange i was looking this thread 10 mins ago trying to learn turrets :) .
-
probably you didnt name the vertgroups right ?
i think in blender you have 3 important names first two same name Mesh and Vertgroups and all other textures ?
I recall i had different name for mesh and vert groups (UV) and it gave me same error
Strange i was looking this thread 10 mins ago trying to learn turrets :) .
.. nah ... all of them the same way done, all the same options ... i aether broke something i dont know of or im a really, really, really, blind person lately ...
... you need help whyte turrets ?
-
Yeah ,
I am trying to get it to turn with the joystick input , so far I manage to get .js scripted and no crash lol but I dont understand the process of whats happening because if I use the section of update_frame to rotate geom it simoky says bad call method , if I do it via action_function it does not moan but it doesnt rotate anything .
I go for some food , I will post .js later
-
Ah damn ... now i see ... update - otehr material stuff ... now it doesnt import any materials at all (just leaves a lot of empty material codes in .mtl file for) ... :o
I had no idea the update would come so soon !
well ... could you send me the .js and the mesh-names of the turret components ? ... i could send you back how i have it done whyte your object parameters ...
-
Hmm, are you importing through FBX or Collada?
-
Hmm, are you importing through FBX or Collada?
collada ... doe, adding material names, collor numbers and difuse maps into the file works ... just seems to do blanks there during import in the material definition file, otherwise, its ok.
-
... heh ... seems, the names for materials cant be too long - have made it shorter and now it textures how it should ...
-
Continuing on few things on the Ural - Textured the cabin for the empty and flat-bed versions. The BM-21 unit will take some lot time, so i decided to take those two models to a practical finish, so i can fully commit just to their script-work. Added kilometer-counter and a clock to the front-panel (try making it functional trough all wheel average rotation) and a clock.
Doe, for ya - AngryPig - does weighted bones-deformations apply just to objects (as the mercenary is in that category yet) or could i animate rod-suspensions on the ural axles as in characters, not bind to a animation file, but scripted bone-rotation like any other thing in vehicle-script ? Seems, it could have an interesting (and smooth) outcome for such suspensions on vehicles, also door-cables or other movable stuff, witch could give me too the possibility to do the cabeling on the grad system turret (witch gave me some pain s while back).
(http://m2.aimg.sk/forig/f_455747141_618e6729ee62660fb65647154e3ccb65.png)
(http://m4.aimg.sk/forig/f_455747147_eca0dafe0957f92d8e02cd3f7d2731ff.png)
(http://m4.aimg.sk/forig/f_455747135_89a2684a8b3b1129d7d43639864a57e7.png)
... dont mind those interior GTA-ViceCity texturing skills. :D :D Also, Blender renders in double-sided mode, so dont mind the "transparency" there aether, will be good after import anyway.
-
Not sure if you mean this, but you can easily smoothly animate objects in script too, for example take a look at this:
Karosa ŠM 11 (http://www.youtube.com/watch?v=whIJrbvLb0M#ws)
It uses the built-in javascript axis_integrator class (http://xtrac.outerraworld.com/trac.fcgi/wiki/action_code), that helps with integrating a value over time, with given max speed and acceleration of the value change, that is then used to control the rotation.
const MaxDoorSpeed = 60; //deg/s
const MaxDoorAccel = 1200;//deg/s^2
function init_vehicle()
{
//create new integrator for the doors
this.d1 = new axis_integrator(radians(MaxDoorSpeed), radians(MaxDoorAccel), 0, radians(90));
...
}
//handle extra actions
function action(k,v,dt)
{
switch(k){
case AOpen: if(v) {
//set the direction of doors opening/closing operation
var d = this.d1.value>0 ? -1 : 1;
this.d1.set(d);
}break;
}
}
function update_frame(dt, engine, brake, steering)
{
var ax = {y:-1};
//if the integrated door value changed, rotate the door wings
if(this.d1.changed(dt)){
this.geom.rotate_joint_orig(d1[0], this.d1.value, ax);
this.geom.rotate_joint_orig(d1[1], this.d1.value, ax);
this.geom.rotate_joint_orig(d1[2], -this.d1.value, ax);
}
...
-
YES! DESERT BUS! ;D
-
Well, characters have mesh faces assigned to them (the assigning part in blender is called weight-painting/weighting if i confuse you later in text), where the area between two bones is deformed smoothly (like elbow/shoulders of the mercenary when it moves). So i thought, if i do something like a character-bone skeleton for the leaf-springs (sorry, miss-spelled that as rod-suspensions in post before - always forget that term) and use script-rotation for their bones in accordance of the axle height ( and angle --- well, character animations are done so, that every action refers to an external "animation file" that says witch rig-bone rotates how at witch time-segment (can be seen good at the mercenary folder files too), but i would use them just like other ones in vehicles ), it would look greatly smooth driving on them instead of splitting the leaf-springs into several parts and do the same for a split-mesh thing, where it would be clear, that its a multiple-mesh animation (not much an eye-candy and for that height-variation the Ural has, i would have to split them to 10 parts at-least to make it look somehow better).
Oscurart Blender Tutorial Rope Rig (http://www.youtube.com/watch?v=3sDMHCXYSQ8#)
... yes, several-piece anims arent a problem (like the door you showed) - but cables/ropes/leaf-springs - they would need this kind of stuff. Im just not sure, if the vehicle-importer takes these kinds of bones as it should like when you import a character. (would try it myself, but am yet again at school for the next month or so and wonder if i should prepare this things too in the blender model).
You can see the SpinTires guys done actually that in their ZIL -- watch the back-wheel plate suspenders, you can clearly see, its not three meshes, its just one, deforming nicely in the middle part (only thet they used just one long bone in the rig to each wheel - i would use 4 for each side) :
SpinTires Tech demo | Suspension test | gameplay 2 (http://www.youtube.com/watch?v=edjGngIDulM#ws)
Car Suspensions: "Spring Harmony" 1935 Chevrolet Auto Mechanics (http://www.youtube.com/watch?v=mZzfIFBXx5Q#)
( just to achieve these leave-springs working nice in animation whyle driving around - just as in this vid -- its kinda funny too as it is such a historical document :D We should make an funny presentation video about OT vehicles whyte that voice-acting :D :D )
Also, i think thats the way they done Wheel-rubber deformations - just adds a set of bones in a star-like fashion (i think 12 of them would be enough to give a nice effect - also have to note, those rig-bones have this specialty, to not only rotate, but get shorter/longer - mostly used in movie-animation doe) from the center of the wheel and they are set to get shorter once facing down to ground a certain angle (if having connection to the ground - maybe there is another variable in there to show kinda "tire-pressure" too witch affect the depth of deformation (you know, to variate the max. shortening of them when the axle angle goes so high, that one of the wheels is in air, or the car jumps/hangs over a ditch) ).
Maybe, there would be a way to automatize this for the future importer ! But you'd have to pick the tire-meshes and set the tire radius beforehand for it (well, plane on witch the star rig-bones would be lying are Y and Z and they all come from the pivot point, witch is in center of the wheel - should not be so much problem). But the importer would have to do the "weight" automatically (now when i think, maybe there are just shorter ones at the tire perimeter, that deform, to simulate the deformation only at the right area and not the whole rubber part of the wheel - maybe even two-segment star-like bone structure, where outer ones deform more than inner ones to simulate the deformation-profile much accurately. But here is no problem to set more radius-es in the importer to do such stuff). Also, the rubber wheel part would have to be a separate mesh to allow that the inner metal part doesn't do stupid things there (but simulation of tire-damage or tire-changing would need such a thing anyway) and possibly the deformation would need its own spring-constants and dynamics for the bones shortening/stretching. But it would be interesting to have the dynamics of the vehicle being enhanced trough this star spring-wheel structure. Maybe isnt as much work to get it work nicely whyte the bullet physics.
(http://2.bp.blogspot.com/-Om3YPnu3fv8/ThWwBQGh6_I/AAAAAAAABeg/Cy-cZWtG17k/s1600/spring-loaded-bicycle-wheel.jpg)
I could do that star rig-bone structure for each wheel manually, but i think people from the vehicle-Sim community would be very impressed by such a tool enhancement in this engine. (saves a lot of time setting this things manually for all vehicles - but probably hawing them in script, to it could be made variable for different surface traction and tire animation simulations) ... Doe, some automatic weight-paint would have to be scripted (as blender or 3DMax has in its tools) to OT, not sure how that is gonna turn out. :/ ??? :/
- but yes, this kind of modding stuff has plenty time, you have surely your own priorities now whyte clouds weather or whatever you need to do first, now im just curious if the importer takes the weighted rigging well for a 4-rig-bone leaf-spring for a vehicle right now.
forgot to say - airless wheels are the future of Earth and interplanetary vehicle design - need this surelly for the AntenWorld storyline home-comers !! :D :D :D No worries about tire-pressure manipulations for different surfaces - in future, at one, outer resins will be enhanced to get better grip on more various surfaces and also the "springletts" will be some kind of electro-sensitive thermoplastic composite to make its stiffness (spring-constant) variable and controllable. I stake my chemists guts on that. Also be much more easy to recycle entire tires material this structured way. :)
Airless tire test Humvee vs Hummer (http://www.youtube.com/watch?v=4jYcX_D09ig#)
P.S.: - hi-five and thumb-up for that bus model to its creator - nice work there !
-
A little further paint job ... hope i can import and upload it in near time, but expect an texture-file explosion ... :D
(http://m4.aimg.sk/forig/f_456127359_5792a0d3aa11af2a00905c4146799e53.png)
(http://m1.aimg.sk/forig/f_456127352_8e2298ff51c8174459192a8e062a6a14.png)
(http://m1.aimg.sk/forig/f_456127344_21a7efae7ea591b6a5a78bea92a5cb93.png)
-
Have a few things to ask after a little whyle on scripts.
https://drive.google.com/file/d/0B3ZscF0ox2AGSXhsNVBST1h4b1E/edit?usp=sharing (https://drive.google.com/file/d/0B3ZscF0ox2AGSXhsNVBST1h4b1E/edit?usp=sharing)
... i want to try making the vehicle variants in one just by changing a constant in the script ( see at the beginning, the defining parameters ) as a search tool for mesh-problems and set-up-check for the different variants. Im not sure if its, cause i put the IFs part into the "init vehicle" script section ( but i would like to be sure ) but it kinda ignores the IFs and takes automatically the first instances. I tried to put it elsewhere, doe i may have some stupid error there somewhere ( see the IFs from line 653 ).
Also, tampering whyte the axle suspension anim., i registered, that the value of the "wheel-height" (z axis deviation from normal position) just goes instantly to zero position, when there is no contact whyte the ground. I made an empty-mesh for the actual wheel and a mesh-wheel for animating its movement (actually relates angle deviation of the axle). The thing is, that normally a wheel goes smoothly to its zero position accordingly its damper. constant if the vehicle jumps. Also, when loosing the ground connection, the wheel should rotate along due to inertia, but the "var wflrot = wfl.rotation;" seems to give an instant zero at that moment, freezing the script animated wheel-mesh. ( if im right, it seems to be computed as a time change of the rotation till to 2*Pi and over again )
Did you know and have you in mind something to tamper this problem somehow in the future ?
-
"this" refers to the active vehicle object, and it's valid only in the functions that are invoked from within the engine: init_vehicle(), engine(), action() and update_frame.
Outside of these functions you can define normal Javascript variables or constants. That means that:
this.CarType = 1; // This one changes the layout of the vehicle to severall mods.
this.FilterType = 1; // This lets you choose the engine filter type
this.CamCow = 1; // This lets you choose the engine filter type
this.Fend = 1; // back-fender type ( rubber / metal )
... doesn't make sense in the global scope. It should be defined as:
const CarType = 1; // This one changes the layout of the vehicle to severall mods.
const FilterType = 1; // This lets you choose the engine filter type
const CamCow = 1; // This lets you choose the engine filter type
const Fend = 1; // back-fender type ( rubber / metal )
Also note that you can put these parameters into objdef file, e.g. if you make copies of objdef files that are supposed to be variants of the vehicle, you can put parameters that determine their properties into the "parameters" field in the objdef file, for example "parameters" : "tire_size:1.2, engine_power:20".
These params then appear in optional argument of init_chassis:
var engine_power;
function init_chassis(param)
{
var par = eval(param);
//set global var to be used for engine power (in update_frame)
engine_power = par.engine_power;
//use par.tire_size when defining the wheels
...
}
A few more notes: static stuff like mesh ids can be defined as global variables in the script, e.g. not queried in init_vehicle and attached to "this", but queried in init_chassis and set as global variables, since they are the same in all vehicle instances.
You should define variables under "this" only when they change per vehicle instance.
The wheel info data given to the script are probably zeroed when there's no contact, I have to fix that as even internally they aren't zeroed.
-
Thanks Cameni, will try something whyte that ...
-
Is there a way to make an axis-integrator pause/start ? At one point - is kinda weird, that opened stuff doest still at positions where their left, when i change from one to another (in my new ural cars). On secon, im just such a noob that i cant figure out an working into infinity pause-able seconds counter. That thingy should be used for an fuel-system and a driven km-counter.
-
Simply do not call the .changed(dt) method on it when paused.
-
The instant 0 positioning when the tires leaves the ground is why vehicles LOOK odd when driving in outerra. They always seem to be on the cusp of taking off and the wheels move un-naturally. Next we have to get some MASS on the wheels to help with momentum and balance.
-
Simply do not call the .changed(dt) method on it when paused.
... you mean, doing some On/Off variable where at off the .changed(dt) wont be applied and reapplied, like this one little function has ? http://whatanswered.com/websites-javascript/javascript-simple-start-stop-timer.php (http://whatanswered.com/websites-javascript/javascript-simple-start-stop-timer.php)
The instant 0 positioning when the tires leaves the ground is why vehicles LOOK odd when driving in outerra. They always seem to be on the cusp of taking off and the wheels move un-naturally. Next we have to get some MASS on the wheels to help with momentum and balance.
Yes, sometimes it behaves odd. Some flow movement from the last contact height to the zero position (not the model one, but the suspension one) would be needed. Also, "power" at climbing is not real. Sometimes should wheels slip when the climb is too steep to move forward. But i wouldnt take it as a so "primary" flaw yet in development. Also, maybe it will be unnecessary when some wet terrain-deformation hits OT. :D
-
... you mean, doing some On/Off variable where at off the .changed(dt) wont be applied and reapplied, like this one little function has ? http://whatanswered.com/websites-javascript/javascript-simple-start-stop-timer.php (http://whatanswered.com/websites-javascript/javascript-simple-start-stop-timer.php)
Not sure what you want the pausing for, but the integrator is technically a variable that accumulates value depending on elapsed time and the desired action. If you do not call the "changed" method, the internal value doesn't change.
What is cabcount in your script? Because it's used as a global variable, therefore all instances of vehicles use the same variable. Should be this.cabcount if you want it to pertain to a single vehicle instance.
On the other hand, some things are global and you are creating them for each instance - for example vehicle joints.
-
The cabcount was used for a hit-counter - for selecting a specific thing to open. If yore looking at my script - see the integrator opening stuff at the :
//invoked each frame to handle the inputs and animate the model
function update_frame(dt, engine, brake, steering) {
// Object rotations
// Door windows
var ax = {z:-1};
if(this.d1.changed(dt) && cabcount == 4){
this.geom.move_joint_orig(this.dlw, {x:0,y:0,z:-this.d1.value});
}
...
// Front pannel cases and hood
var ax = {x:-1};
if(this.d5.changed(dt) && cabcount == 1){
this.geom.rotate_joint_orig(this.cc, -this.d5.value, ax);
May be a rough way to do, but works for me ...
The pause would be used when the engine is off - when its on the counting would go on. On this variable, would specify a fuel-consumption script dependent at EngineRPM and actual gear setting. Also another one, for when the vehicle moves (vehicle speed bigger than 0) to make a traveled distance meter (depending on actual speed and time driven) for the front-panel rotameter.
-
But you don't need the axis_integrator for that. Just initialize another variable in init_vehicle, like this.engine_on=false, and then in function engine(start) { this.engine_on=start; ... }
Then in update() you'll do the counting:
if(this.engine_on)
this.fuel -= Lper_second*dt;
... provided this.fuel was initialized to some starting value.
Same with the traveled distance, except there you can just unconditionally do
this.distance += this.speed()*dt;
.. to get the distance in meters.
-
But you don't need the axis_integrator for that. Just initialize another variable in init_vehicle, like this.engine_on=false, and then in function engine(start) { this.engine_on=start; ... }
Then in update() you'll do the counting:
if(this.engine_on)
this.fuel -= Lper_second*dt;
... provided this.fuel was initialized to some starting value.
Same with the traveled distance, except there you can just unconditionally do
this.distance += this.speed()*dt;
.. to get the distance in meters.
... just "*dt" the value ? ... i still dont grasp fully how that differential works (per frame or 1/1000 of a sec). Might as well done something else wrong in that older attempt ... have to investigate that. (cant quite turn my head around when i dont see the time development in things)
-
dt is the elapsed time since the last call. With any rate-type value like velocity [m/s] or fuel consumption [liters/s] you can get the distance or fuel consumed since the last call by multiplying it with dt.
-
dt is the elapsed time since the last call. With any rate-type value like velocity [m/s] or fuel consumption [liters/s] you can get the distance or fuel consumed since the last call by multiplying it with dt.
... damned, works like charm - i should throw away some time-dimension concepts when playing white scripts. But still - if im right, the last call is dependent on the CPU computing speed and the stuff it has to do whyle going trough the script-stuff ? (yes, its probably not so much a difference) ... dont want to see the corrections for that for real-life super precise applications (they must go crazy at the CERN, both mathematicians and programmers).
Also a new idea - for turning-blinkers, you need to know if youre turning. I could use a script depending on the "seering" variable (and probably will do that, till i think of some separate blinker key-use, but still would need go trough them all as i plan to adjust even revers-mirrors and a lot of other stuff too later on), but when a script would need to know, if ya holding the turning-left/right, front, back key on the keyboard, how do they look like ? Is there too an action code for them ? (http://xtrac.outerraworld.com/trac.fcgi/wiki/action_code (http://xtrac.outerraworld.com/trac.fcgi/wiki/action_code))
-
No, this is currently handled outside of the script (together with steering wheel return to zero upon release). But for an advanced steering control we probably should add them.