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 ... 3 4 [5] 6 7 ... 11

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

Jagerbomber

  • Hero Member
  • *****
  • Posts: 1563
Re: Limits of functionally designed models ?
« Reply #60 on: August 17, 2013, 01:09:31 pm »

We don't know what you mean by a "great drop."
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 #61 on: August 17, 2013, 03:58:59 pm »

We don't know what you mean by a "great drop."
§

like 6-13 FPS  ;D   it really needs other LODs done afterwards ...
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.

Jagerbomber

  • Hero Member
  • *****
  • Posts: 1563
Re: Limits of functionally designed models ?
« Reply #62 on: August 17, 2013, 04:05:00 pm »

Is that how much you lost or how much you got down to?
« Last Edit: August 17, 2013, 04:06:35 pm by Jagerbomber »
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 #63 on: August 17, 2013, 04:18:36 pm »

Is that how much you lost or how much you got down to?

 .. got down to that number ...
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.

Jagerbomber

  • Hero Member
  • *****
  • Posts: 1563
Re: Limits of functionally designed models ?
« Reply #64 on: August 17, 2013, 04:39:22 pm »

Um... That's not a good thing. ?  :-\
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 #65 on: August 18, 2013, 01:09:56 am »

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.
« Last Edit: August 18, 2013, 01:11:30 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.

John514

  • Hero Member
  • *****
  • Posts: 543
  • Certified TARDIS driver.
Re: Limits of functionally designed models ?
« Reply #66 on: August 18, 2013, 03:48:33 am »

Arent the LODs made by the engine itself?
Logged
You mustn't be afraid to dream a little bigger, darling

Note: I do not claim to know everything.
I just like to help people around the forum.

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #67 on: August 18, 2013, 04:43:54 am »

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

John514

  • Hero Member
  • *****
  • Posts: 543
  • Certified TARDIS driver.
Re: Limits of functionally designed models ?
« Reply #68 on: August 18, 2013, 05:40:10 am »

Intereseting... Makes me think if adoptive tesselation could be adopted...
Logged
You mustn't be afraid to dream a little bigger, darling

Note: I do not claim to know everything.
I just like to help people around the forum.

PytonPago

  • Hero Member
  • *****
  • Posts: 2284
  • It´s way too complex, dont let me try to explain !
Re: Limits of functionally designed models ?
« Reply #69 on: August 28, 2013, 10:20:33 am »

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 ...
« Last Edit: August 28, 2013, 10:22:30 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 #70 on: September 11, 2013, 05:15:22 pm »

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

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.
« Last Edit: September 11, 2013, 05:48:31 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.

Timmo

  • Member
  • **
  • Posts: 77
Re: Limits of functionally designed models ?
« Reply #71 on: September 11, 2013, 07:12:53 pm »

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?
Logged

cameni

  • Brano Kemen
  • Outerra Administrator
  • Hero Member
  • *****
  • Posts: 6721
  • No sense of urgency.
    • outerra.com
Re: Limits of functionally designed models ?
« Reply #72 on: September 12, 2013, 01:13:13 am »

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

PytonPago

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

so the "case ... break" separates them from each other, but time depending variables must stay just the k,v, (or whatever i choose) ?
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 #74 on: September 12, 2013, 09:46:54 am »

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:

Code: [Select]
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;
Logged
Pages: 1 ... 3 4 [5] 6 7 ... 11