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 ... 14 15 [16] 17 18 ... 30

Author Topic: Importer  (Read 241694 times)

mustang60348

  • Member
  • **
  • Posts: 92
  • newbie
Re: Importer
« Reply #225 on: November 23, 2012, 08:34:12 am »

Are multiple engines supported in Outerra yet, if not, any ETA on that support
Logged

angrypig

  • Sr. Member
  • ****
  • Posts: 454
Re: Importer
« Reply #226 on: November 23, 2012, 12:38:56 pm »

Are multiple engines supported in Outerra yet, if not, any ETA on that support

The only issue there is that we start first engine only but you can overcome this issue in the script. We are working on a few updates to the JSBSim stuff which will fix this issue...
Logged

mustang60348

  • Member
  • **
  • Posts: 92
  • newbie
Re: Importer
« Reply #227 on: November 23, 2012, 02:25:07 pm »

Thanks for the update
Logged

seppen

  • Full Member
  • ***
  • Posts: 130
  • newbie
Re: Importer
« Reply #228 on: November 23, 2012, 05:28:18 pm »

I´ve been away on some wild ride in vacation, and needed vacation to recover from it lol, but is collision ahead anytime soon?

I know all the buzz is about Roberts space thing, I love it!, but it´s limited by Cryengine, so Outerra is the future if can get funding.

It´s not easy to test local architecture, infrastructure if no collision, and I´m a flightnut by the way! so it´s not about my needs.

The wet dream of all that is not transissions from space outside into space inside etc need to be done..

I´m still in need of the freedom Outerra provide, so detailred stuff on the ground is important 2.

I will feel better on Monday lol, noticed Cameni´s hard day remark!, call it hard weeks.
Logged

mustang60348

  • Member
  • **
  • Posts: 92
  • newbie
Re: Importer
« Reply #229 on: November 25, 2012, 08:10:17 am »

Are multiple engines supported in Outerra yet, if not, any ETA on that support

The only issue there is that we start first engine only but you can overcome this issue in the script. We are working on a few updates to the JSBSim stuff which will fix this issue...

Could you post a code snipit for getting the engine started via code, I have looked in the docs for jsbsim, can't find it
Logged

mustang60348

  • Member
  • **
  • Posts: 92
  • newbie
Re: Importer
« Reply #230 on: November 25, 2012, 11:11:38 am »

Quick progress on my model (OV10 Bronco)

Got her in the engine, got a rudimentary FM done.

Got propellers animating with engine speed
Got all control surfaces animating
Got the control stick, throttle, rudder pedals and flap level animating

SO far it is going quite nicely

Logged

ddenn

  • Sr. Member
  • ****
  • Posts: 374
Re: Importer
« Reply #231 on: November 26, 2012, 06:25:00 am »

LOD_CURVE is for LOD switching, provided that you actually have multiple levels of detail in the model, otherwise it's ignored.

I've tried to use LODs and get strange result, the first 2 LODs are useless because they changes when I'm very near the model (and "lod_curve" doesn't seem to do anything), and the others two LODs change the texture from one material to the other.
Logged
i7 3930K 3.50 (3.80) Ghz, 32Gb RAM, GTX980 4 Gb VRAM, Windows 7 64-bit

About Outerra in Russian

angrypig

  • Sr. Member
  • ****
  • Posts: 454
Re: Importer
« Reply #232 on: November 26, 2012, 09:34:46 am »

LOD_CURVE is for LOD switching, provided that you actually have multiple levels of detail in the model, otherwise it's ignored.

I've tried to use LODs and get strange result, the first 2 LODs are useless because they changes when I'm very near the model (and "lod_curve" doesn't seem to do anything), and the others two LODs change the texture from one material to the other.

lod_curve doesn't work, i made a lot of changes there and forgot to restore LOD functionality, currently it's using default value for all objects. :(

Logged

monks

  • Full Member
  • ***
  • Posts: 212
Re: Importer
« Reply #233 on: December 03, 2012, 05:55:33 pm »

Hey guys, quick question on the 3D importer. How does the importer handle terrain changes? When ME-DEM releases a terrain, and that terrain changes in a subsequent release (likely in certain places), will any models adapt to it easily?

monks
Logged

cameni

  • Brano Kemen
  • Outerra Administrator
  • Hero Member
  • *****
  • Posts: 6718
  • No sense of urgency.
    • outerra.com
Re: Importer
« Reply #234 on: December 04, 2012, 01:36:46 am »

That's a good question :)
Right now the static objects you place are positioned absolutely. That's how the Lukla scenery passed away - we imported new dataset that was slightly higher at places, and Lukla sank into ground like a prehistoric city. Although, we could have adjusted the offset easily, the problem was a bit different there - the old dataset was also shifted by half the sampling distance due to a bug, and since in Lukla everything depends on the topology, it suddenly wasn't easy to repair.

We need relative positioning there, but it must not be hooked onto the fractal detail as that may change when we make changes to the algo.
Logged

monks

  • Full Member
  • ***
  • Posts: 212
Re: Importer
« Reply #235 on: December 04, 2012, 06:21:09 am »

Sunken citys...? Might be a quick and easy way to build Moria- build on surface and then change terrain :-D
 Just looking ahead..so given that you're aware of the bug, the offset should apply easily. But, in ME-DEM's case, it won't be a straight offset for all terrain points. I've not used the importer yet so I've no idea of the mechanics of it- the GUI, etc.
 It would be convenient if the importer could store x,y but allow for a drop to terrain for z value. That would help...I guess there's no foolproof way to procedurally adapt the models....unless your relative positioning idea solves that.
 As soon as we put this version 1.5 out, I'll probably move straight onto making the improvements so as to minimise problems. Either way though I don't even know if anyone will be interested in using the terrain or building on it yet! I could easily get a reputation of "destroyer of cities" ha!
Logged

mustang60348

  • Member
  • **
  • Posts: 92
  • newbie
Re: Importer
« Reply #236 on: December 05, 2012, 07:16:04 am »

Does the visual model effect how the aircrat interacts with the OUTERRA environment. IOW, is there a collision model built from the visual model by the importer.

I am trying to get a handle on how the FDM and Visual Model interact. The docs are IMHO very confusing for JSBSIM.

For example

For AERORP, lets say you have values of 190,0,60 < what are these number in reference to. My way of thinking says they have to be in reference to something, iow, 190 inches away from WHAT.

Then when you input CG of say 160,0,48 , is the 160 away from the AERORP OR from the original reference point that AERORP uses.
Logged

ddenn

  • Sr. Member
  • ****
  • Posts: 374
Re: Importer
« Reply #237 on: December 05, 2012, 07:24:27 am »

I have the same problem with coordinates, I used wheel reactions to find FDM contact point positions when I started work on Sh2, but after the updated I could not do same for some reason. So I'm waiting for visual marks for contact points now.
Logged
i7 3930K 3.50 (3.80) Ghz, 32Gb RAM, GTX980 4 Gb VRAM, Windows 7 64-bit

About Outerra in Russian

mustang60348

  • Member
  • **
  • Posts: 92
  • newbie
Re: Importer
« Reply #238 on: December 06, 2012, 09:42:02 am »

Here is what I have "DISCOVERED" so far.

AERORP is simply the Base Coord Reference point. In my head I call this the 0,0,0 point. IOW, Everything else is referenced from this. I am developing an OV 10 Bronco and have put the AERORP in the physical center of the A/C. Since I model my aircraft with Y axis running thru the wings, the x axis running thru the center and the Z Axis at the bottom of the wheels. This makes this point most convienent. So my AERORP is 0,0,103 , So AERORP (in reference to my 3d model) is centered forward to back on the wings, centered left side to right side and 103 inches UP from the wheels.

Now when I define the other points I simply enter offsets from this points for things like the landing gear, CG etc.

For example my CofG is 36 inches forward of the wings in the X axis and is -36,0,0 as entered in the XML file. Remember too that the CofG is entered for an empty A/C, so as you add fuel, and as fuel gets used, the CofG actually changes, just like it does in a real aircraft.

As I enter fuel tanks, landing gear etc. I just use the AERORP dummy object I created in the 3d model and measure from it to get my values. So far this seems to have worked for me.

Hopefully this will help someone else.
« Last Edit: December 06, 2012, 09:48:40 am by mustang60348 »
Logged

ddenn

  • Sr. Member
  • ****
  • Posts: 374
Re: Importer
« Reply #239 on: December 06, 2012, 10:10:57 am »

If that's so it is probably wrong. If I understand correctly,  AERORP (Aero Reference Point) should not be base coordinate point (for that we have VRP, visual reference point). AERORP is crucial part of flight model and should have ability to be changed without affecting 3d model/FDM contact points position
Logged
i7 3930K 3.50 (3.80) Ghz, 32Gb RAM, GTX980 4 Gb VRAM, Windows 7 64-bit

About Outerra in Russian
Pages: 1 ... 14 15 [16] 17 18 ... 30