[DGIV BLOG] News about devellopment of DGIV

[DanSteph]

-----------------------------------------------------------------------------------------------
I'll post here from time to time somes news about my work on DGIV,
of course I'll first update the thread related to beta test but sometime
it may only be some thought about my work, mood etc etc... so I'll post
here when a post in beta thread is not suitable.
-----------------------------------------------------------------------------------------------


Okay, first post is related to DGIV cargo bay. I post here because there is no
active beta thread currently.

The DGIV can load any vessel in it's bay (yes even the shuttle) but the config file
must have some parameters related to DGIV. Anyone will be able to make "addons"
for cargo bay using existing mesh or doing new neat mesh. when the DGIV release
a payload this one become an active vessel if it have a dll, mean you can have
complex sattelite with animations etc etc... All this seem logic

Here for example the carina.cfg if you want to be able to carry it. In blue you'll see
the DGI's specific parameters that one must add in the cfg and in bold you'll
see the Orbiter parameters that DGIV need also so it consider the config file as valid.

carina.cfg ----------------------------------------------------------------------------------------------
; === Configuration file for vessel class ESA Carina ===
ClassName = carina
MeshName = carina
ImageBmp = Images\Vessels\Default\Carina.bmp
Size = 5.0
DGIVCARGODESC = Satellite Carina
DGIVBAYPOSITION = 0.0 0.0 -1.40

Mass = 5000; empty mass [kg]
MaxFuel = 0  ; max fuel mass [kg]
Isp = 0        ; fuel specific impulse [m/s]

[SNIP]

; === Attachment specs ===
BEGIN_ATTACHMENT
P 0 0 0  0 -1 0  0 0 1  DGIVCPL
P 0 0.9 0.1  0  1 0  0 0 1  GS
END_ATTACHMENT
-------------------------------------------------------------------------------------


So basically DGIV need only three specific parameters:

"DGIVCARGODESC" Description of payload that will be dispayed on DGIV's panel, 50 characters allowed.

"DGIVBAYPOSITION" Position of mesh in local DGIV's coordinate, to adjust the mesh into the cargo bay.

"P 0 0 0  0 -1 0  0 0 1  DGIVCPL" DGIV will need at least a grapple point named "DGIVCPL" this ensure
first that a Mmu can grapple it but will inform also the DGIV that an object in space can be grappled by it
ie: the config file will contain the requested specific parameter.

On the panel there will be a "grapple/release" button as for turbopack, when you "grapple" something
the DGIV will scan all objects, eliminate those that doesn't have a "DGIVCPL" grapple point and if it found
some will test their positions and closer object will be grappled. Mass of payload will be added to DGIV
(so in fact you can grapple the shuttle but won't be able to take-off )

Here a test with carina, (too big):




I'll make some containers available with stock download of DGIV ... if one want to start playing a bit
doing some cool payload mesh the cargo bay is about 2.90 meter long, 3.80 m wide and minimum height
of 1.34 m (max 1.69 m) Take care the floor is not flat...

Dan



Message modifié ( 14-01-2007 06:29 )

[DanSteph]

About modelling optimisation... for specialists

The completion of my mesh optimizer gave me some more hint about modeling optimisation.
Of course the less textures, material and poly you have the more your model will be easy
with the FPS, less know hint is that change state is FPS consuming so you must usually merge
all groups that have the same material and texure.

This is why I wrote this optimizer to remove some needless texture and material state change.
As groups are not sorted in mesh file Orbiter do something like this when it display a mesh:

TEXTURE SET TO BOTTOM
-->DISPLAY BOTTOM GROUP
TEXTURE SET TO TOP
-->DISPLAY TOP GROUP
TEXTURE SET TO BOTTOM (again)
-->DISPLAY REAR GROUP

Yes we use the same textures for bottom and rear group, so Orbiter switch two time to "bottom" texture.
Of course during modelisation one can merge bottom and rear group, but this is not possible
with animated parts as they require separate group.

I noticed then that when you doesn't set a TEXTURE or MATERIAL parameters at top of group
in the mesh file Orbiter use the current one (the one of the last object displayed) so I thought
that with some sorting of group one can do something like that:

TEXTURE SET TO BOTTOM
-->DISPLAY BOTTOM GROUP
-->DISPLAY REAR GROUP
TEXTURE SET TO TOP
-->DISPLAY TOP GROUP

One texture change saved. For the DGIV my mesh optimizer save about 67 states change using this method.



But fact is that I gained only 4-7 FPS with 5 DGIV displayed, about 1-2 FPS only with one... of course
this is still cool as every FPS gain count but it's not as much as I thought at first. After all I gained
about 40 FPS in the frelon IX model while merging groups during final modelisation. (from ~100 groups to 7)

So the hint is the following: State change aren't as much time consuming then I thought but what is REALLY time consuming are separated groups, THIS is the number to keep the lowest as possible if you want that your
model run well.

Conclusion: Merge groups as much as possible !!!

Dan
Ps: (in 3dmax select one object and use "attach" to merge groups)



Message modifié ( 14-01-2007 07:11 )

[picto]

Ailandt was also speaking about this type of optimization in his tutorial.
He said that one of his VCs is only one big object with only one texture.

But I've been reading also on this  topic that he is going to give the choice
to users : a single object with a 2048 for big computers,
a single object with  a 1024 for smaller ones ...
etc ..

So, are you sure it is a good idea to keep 4 1024 DDS when it is possible
to make a simple 2048 ?
Of course, I understand that it is possible to display two or three DDS
in 1024 format  on medium computers but, may be it would be
a nice idea to try a 2048 instead of 4 1024 dds on a big computer to see
what's the FPS gain.

[DanSteph]

Sure, one texture and one group for the whole model is by far the best technical choice...

But fact is that if most computers can handle a model with 4x 1024 textures, only
the most recents can use a 2048 texture. Many peoples still use 1-2 GHZ with old 3d card. (most of them?)

Of course, you can lower the 2048 to 1024 but in this case, the res
is lowered to 512 for one quarter without any justification.

So with 4x1024 most peoples will be able to run your model with a good resolution
but with the second option the res will be down to 512 without any real need for that
as such computer can handle very well 4x1024 and display them without FPS drop.

In brief You force most people to use a lower resolution only because
their 3d card can't handle the texture overall size.

Choice can be made to make two models, one with all object merged and 2048 for high end computer
where the texture can be lowered to 1024 for crappy computer and the second with 4x1024 for common
computer. But I let you imagine the f texturing work...

Anyway 4 groups instead of one doesn't make such much change,
so the 4x 1024 is the best choice here immho. This is not true
with 20 or 50 textures even with low res... this is THE bad choice.

Dan



Message modifié ( 14-01-2007 07:33 )

[picto]

Bah, in case you have already pack your UVs on 4 small little squares,
I don't think it's very difficult to merge them on a bigger square

[DanSteph]

I edited my post but I repost here as you replied during my edit:

"Anyway 4 groups instead of one doesn't make such much change,
so the 4x 1024 is the best choice here immho. This is not true
with 20 or 50 textures even with low res... this is THE bad choice."

Dan



Message modifié ( 14-01-2007 07:33 )

[picto]

Sorry for rotting your blog.
Can't remember if I've been already saying that I like your payload system
especially  the  panel display ... great idea !

[skookum]

I've been testing re-entry performance of the latest public (now expired) beta release. I am happy to report the DGIV
performs beautiful re-entries with comfy temperature and energy margins. All re-entries were initiated from a 200km by 200km
orbit. Burn retrograde at the crossover distance to your intended base (map MFD). Set PeA to 40 KM AGL. Dump fuel leaving
10-15 percent for final approach. By holding the numbers provided by GlideslopeMFD
http://orbithangar.com/searchid.php?ID=2763 the pilot will see the nose temp peak at around 900 degrees
centigrade. The DGIV re-entry autopilot still needs more AOA and Bank angle selections for fine tuning the approach, but it
is still extremely handy (if not mandatory) as is. The AOA hold autopilot included with Glideslope MFD is useless with the
DGIV. The L/D ratio on the DGIV Drops dramatically after 20 degrees AOA and GlideslopeMFD's AOA hold cannot compensate for this.

Once again, if you are experiencing difficulty re-entering in the DGIV, do not fret. Practice, practice, practice.

[sunshine135]

Very nice payload system Dan.  It reminds me a lot of the single-line PAYLOAD command on the Generic Payload Description
System (GPDS). The only exception is you are modifying the CFG of the object.  Anyone familiar with any CVEL add-ons should
have no issues using your payload bay.

I'm getting excited about the new bay and performing some EVAs for beta testing. I'm smelling all kinds of cool and new types
of scenarios.

Keep up the great work. We're not worthy!!!!!

Kind regards,

"Sun Dog"

P.S. I used the lull in testing, and I purchased a Nvidia MX4000 3d Fuzion video card. It is 128MB- not screaming fast, but
certainly better than the 32MB on the board Nvidia I was using before. On the even brighter side, I gained that 32MB back in
RAM also. No more chop in sound, and the lowest frames I got were about 14FPS with everything maxed out during launch. If
things get choppy again while testing I'll do a RAM upgrade.

[DanSteph]

Continuing blog....

Previously a failure of door, gear, antenna, etc etc (mainly due to airspeed or crash) simply closed
the door by half, this prevented you to reenter as hull temperature resistance
where lowered also but was not very explicit. I had again the question lately,
after a crash landing a guy asked "why my hover door are half closed ?"

Now the door or the gears simply disappear and some debris are spawned instead
at the place where the gear or door was; nosecone, gear, cargo door, turbopack
door, antenna, cockpit etc etc...

Here we started with all door open and the airspeed just broke them all:



Oh, DON'T ask me for real damaged looking doors or system, I don't think any other
ship in Orbiter is now more complex than DGIV, I don't want to double the mesh part ( wow FPS)
and add 2'500 lines of code to the 30'000 existing just to allow you to damage MY ship...

Anyway a smooth crash landing look better yet with debris coming from bottom....


ABOUT SKINS:
Now skin can be selected by scenario editor, you can edit one ship to change it's skin
or change the skin when spawning one. The change apply immediattely and will
be savec in scenario.  Still this will not work it you have set a specific
skin and not "set by scenario" in dg4config. I'll modify dg4config to warn user that
choosing skins is better if done by scenario editor.

Still there will NOT be full configuration by scenario editor as door or other systems.
DGIV is too complex to be edited like that, this would be a call for several logic bugs
as the sim don't run normally when using the scenery editor.


Dan



Message modifié ( 15-01-2007 09:20 )

[sunshine135]

8o 8o 8o 8o 8o 8o 8o 8o 8o 8o 8o 8o 8o

Dan,

I was just thinking last night about doors and hatches being ripped off by dynamic pressure. Its like you are inside of my
head!!!!! The DG IV is by far going to be the coolest and most flexible ship ever in orbiter.

If the doors get ripped off of the cargo bay, will you be able to see the cargo inside?

[DanSteph]

sunshine135 a écrit:
If the doors get ripped off of the cargo bay, will you be able to see the cargo inside?

Sure, when door are closed the payload is hidden (as you don't see it it would be idiot to loose perf to display it)
but when doors open or doors ripped you see it.


ABOUT HUGE DGIV SCENARIO:

One line per value is an programming heresy and have an impact on loading time. One must know that
each line of scenario is tested with each value expected. So when you have 50 line each line is tested
50 time (a bit less in reallity) this make about 2500 tests, 5000 with two DGIV 8o

Also apart for usefull value as setting, fuel level, pax name , fail state, much values aren't very usefull as you
may just launch the scenario, click on buton and save. Some other can't be changed because it may cause bug.

So, I just saved more than 56 lines in scenarios ie: instead of such things:

StartPower_ext 0
  StartPower_batt 0
  StartPower_cell 0
  Apu_start 2
  Gen1 2
  Gen2 2
  GenSelector 1
  PowerHud 2
  PowerMfd 2
  PowerRadio 2
  PowerAirlock 2
  PowerEngine 2
  PowerLifepack 2
  PowerAp 2
  PowerMainBus 2
  PassengerSeat 1
  Strobe 1
 
...etc etc

You have that: (here the 53 lines saved reduced in three line):

But1Cockpit 0 0 0 2 2 2 1 2 2 2 2 2 2 2 2 1 1 0 1 0 0
But2Cockpit 0 0 0 0 0 0 0 0 2 2 2 2 0 0 3 0 0 0 1 1
LifeBut1State 2 2 1 2 1 2 2 2 2 2 2 2 2 0 0


Old scenery are "compatible" (will not cause problems) as DGIV load default stable value when it don't find them in scenery (ie cockpit and systems On with buttons on usuall value for flight)

Maybe it's just an impression but it seem that even on my PIV 3.2  Orbiter load faster now.
To be confirmed by team.

Dan



Message modifié ( 15-01-2007 17:58 )

[Quick_Nick]

About the cargo bay: You could put a third turbo pack in there for when you have a pilot and two crew. Then if you
have 4 crew, the pilot gets a turbo pack, a crew member gets one and attaches himself to another crew member, and
another crew member does the same. This saves EVERYONE!

[Schimz]

DanSteph a écrit:

You have that: (here the 53 lines saved reduced in three line):

But1Cockpit 0 0 0 2 2 2 1 2 2 2 2 2 2 2 2 1 1 0 1 0 0
But2Cockpit 0 0 0 0 0 0 0 0 2 2 2 2 0 0 3 0 0 0 1 1
LifeBut1State 2 2 1 2 1 2 2 2 2 2 2 2 2 0 0

Dan

Much more pratique.

[DanSteph]

Quick_Nick a écrit:
About the cargo bay: You could put a third turbo pack in there for when you have a pilot and two crew. Then if you
have 4 crew, the pilot gets a turbo pack, a crew member gets one and attaches himself to another crew member, and
another crew member does the same. This saves EVERYONE!

Excellent idea, took 30 sec to do, now turbopack are "DGIV cargo compatible"



Dan

[Voyager]

Question Dan, The Turbopack in the cargohold looks nice but does the cargo bay support multiple payloads?

It seems like a waste to use the whole cargo bay for just a small Turbopack

Ok i can understand it would take alot of efford to support multi payload capabilities, especially if you have to make
buttons for it. So how about this:

Adding a emergency Turbopack to the ship attached to the front end of the cargobay (about there it is located on
your picture, but attached to the side of the cargo bay). The user can decide wether to want this emergency turbo
pack or not, by changing a setting in your nice DGIV configuration program, in favor of more cargo space.

Then all you need on the lower panel is one of those nice secure flip switches to release it, perhaps something like
this?:



and off course release it if you eject. Or if it too much work, then ignore my idea A third turbopack would just help
greatly when you eject a crew of 5 in space

[DanSteph]

I had already some thought about this... (I'm working on cargo right now it work COOL)
multi cargo would be nice and can be done howewer the price is: a lot of time,
and more complexity for users.

Let me explain.

If by any chance peoples start to do cargo payload for DGIV one don't want to have merged
mesh everywhere in the cargo bay. That would be idiot, unrealistic and would not look good.

So one idea would be to have another parameters in config with X and Z size of payload
so you can load one satellite on the left, two turbo pack on rear and one small container
on the right for example. or two big container (left/right) etc etc.
The DGIV will take care of coordinate and refuse grappling or to add a payload if two
are on same area.

But now is another problem: defining a new payload is just plain simple yet, create
the mesh that fit in cargo, add name and position in config file and you just created
a new DGIV payload. With coordinate it become just a bit more tricky. (one must be
precise with size, giving wrong informations will create visual problem and peole will start to
complaint about such "bug"...)

At first I would say I really have enough work yet... I still have some other idea, the doc
promise to be a huge work (that I'll hate as much as I love doing the DG) and I'll already
have problem to finish for end of january as I promised myself.

So at first it's sorry NO !

but multi payload look so cool....

Nah... mhh yes... wait no I can't do that, no enough time... well... no .. really...

Damn !

Dan

PS: and if I do that and no one release "cargo addons for DGIV" ? another useless work ?
(I expected to have new ascent autopilot, hud config and some more stuff that one can
modify since DGII but no one came with such things, giving possibilities take a lot of
time and if no one use them it's just a loss of time)



Message modifié ( 15-01-2007 23:49 )

[DanSteph]

removed useless post

[DanSteph]

More simple. juste zone and name them in one parameters:

For example:
DGIVPAYLOADZONE = ABCD      //would fill the entire bay
DGIVPAYLOADZONE = AC          //would fill the entire left bay
DGIVPAYLOADZONE = A            //would fill the A zone only

So one cannot load a "A" payload with an "ABCD" for example



Nah ... no time... to bad ... was a good idea..
Also if by any chance some do payload they may ignore this parameters
or put whatewer wich will destroy the purpose of it.

Dan



Message modifié ( 16-01-2007 00:10 )

[Voyager]

Just keep it in reserve then, for future development, or if you find some time, the DGIV is very nice as it is

[DanSteph]

DGVI ?

[SHV0151]

Its an awsome idea, but I think that the DG is too small of a ship for multipul payloads



Post Edited ( 01-16-07 00:50 )

[Voyager]

one where your MMU's can get in? :P

what about a rover like thing for cruising on a planet? :P

[sunshine135]

DanSteph wrote:
DGVI ?

Now that one is going to be really fun to Beta Test!!! My eyes are as big as golf balls, especiially for someone who likes
playing around with Space Station Building blocks. Big cargo is a blast.

I'm chomping at the bit to play around in Spacetech's newest glider, and we are already talking about the DGVI. If we don't
leave you alone Dan you will have us flying around in totally different machine.

Kind regards,

[DanSteph]

Blog continuing

Panel almost finished (text look good?)
Grapple/release work flawlessly...

Same system as Ummu turbopack grapple/release, zone around cargo bay is scanned for compatible object
and if one found this one is grappled.

Release/grapple can also be operated with new keyboard key "j" so you can watch
from outside the release.



Dan



Message modifié ( 16-01-2007 23:34 )