Outerra forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Outerra Tech Demo download. Help with graphics driver issues

Pages: 1 ... 8 9 [10] 11

Author Topic: Limits of functionally designed models ?  (Read 86069 times)

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #135 on: February 15, 2014, 12:16:03 pm »

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 ?
« Last Edit: February 15, 2014, 12:17:36 pm by PytonPago »
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

DeanosBeano

  • Full Member
  • ***
  • Posts: 106
  • newbie
Re: Limits of functionally designed models ?
« Reply #136 on: February 15, 2014, 12:30:08 pm »

 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
Logged

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #137 on: February 15, 2014, 12:53:49 pm »

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 ...

« Last Edit: February 15, 2014, 03:09:47 pm by PytonPago »
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

cameni

  • Brano Kemen
  • Outerra Administrator
  • Hero Member
  • *****
  • Posts: 6721
  • No sense of urgency.
    • outerra.com
Re: Limits of functionally designed models ?
« Reply #138 on: February 15, 2014, 01:37:33 pm »

Hmm, are you importing through FBX or Collada?
Logged

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #139 on: February 15, 2014, 03:02:13 pm »

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.
« Last Edit: February 15, 2014, 03:08:00 pm by PytonPago »
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #140 on: February 17, 2014, 03:09:00 pm »

 ... heh ... seems, the names for materials cant be too long - have made it shorter and now it textures how it should ...
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #141 on: March 02, 2014, 10:07:26 am »

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).








 ... 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.
« Last Edit: March 02, 2014, 10:12:08 am by PytonPago »
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

cameni

  • Brano Kemen
  • Outerra Administrator
  • Hero Member
  • *****
  • Posts: 6721
  • No sense of urgency.
    • outerra.com
Re: Limits of functionally designed models ?
« Reply #142 on: March 02, 2014, 11:15:36 am »

Not sure if you mean this, but you can easily smoothly animate objects in script too, for example take a look at this:



It uses the built-in javascript axis_integrator class, 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.

Code: [Select]
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);
  }

  ...
Logged

Jagerbomber

  • Hero Member
  • *****
  • Posts: 1563
Re: Limits of functionally designed models ?
« Reply #143 on: March 02, 2014, 11:42:45 am »

YES! DESERT BUS!  ;D
Logged
"Perhaps this speaks to some larger trend within society today...  A prevailing desire on the part of indie developers to recreate the entire world into one where you can charge more than $15 for your game design degree coursework." - Yahtzee ;) :P

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #144 on: March 02, 2014, 01:36:18 pm »

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).



 ... 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) :




( 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.



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. :)



P.S.: - hi-five and thumb-up for that bus model to its creator - nice work there !
« Last Edit: March 02, 2014, 03:07:29 pm by PytonPago »
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #145 on: March 10, 2014, 05:22:40 pm »

A little further paint job ... hope i can import and upload it in near time, but expect an texture-file explosion ... :D





« Last Edit: March 12, 2014, 08:51:36 am by PytonPago »
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #146 on: March 24, 2014, 11:51:40 am »

Have a few things to ask after a little whyle on scripts.

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 ?
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

cameni

  • Brano Kemen
  • Outerra Administrator
  • Hero Member
  • *****
  • Posts: 6721
  • No sense of urgency.
    • outerra.com
Re: Limits of functionally designed models ?
« Reply #147 on: March 24, 2014, 01:21:35 pm »

"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:
Code: [Select]
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:
Code: [Select]
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:
Code: [Select]
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.
Logged

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #148 on: March 24, 2014, 01:45:33 pm »

Thanks Cameni, will try something whyte that ...
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #149 on: May 27, 2014, 10:02:39 am »

 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.
« Last Edit: May 27, 2014, 10:32:27 am by PytonPago »
Logged
We are still undeveloped as long as we don´t realize, that all our science is still descriptive, and than beyond that description lies a whole new world we just haven´t even started to fully understand.

Pages: 1 ... 8 9 [10] 11