Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter Beta Topics related to Beta releases of Orbiter and Orbiter development.

Reply
 
Thread Tools
Old 10-11-2017, 05:10 PM   #421
Donamy
Beta Tester


Default

Would that include the rotational errors in the attachments, such as the RMS grapple progression also ?
Donamy is offline   Reply With Quote
Old 10-11-2017, 06:03 PM   #422
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by martins View Post
 But I would also want to reconcile this with another idea: taking the building definitions out of the base definitions, and instead define them as an additional surface structure quadtree layer in the planet's surface definition.

This would have the advantage that buildings can use the quadtree LOD and visibility mechanism, rather than having to load the entire base at once (usually long before individual buildings are within visual range).
Makes sense to me. Maybe there could also be some kind of a LOD support for the building meshes itself, so using lower resolution meshes at higher distances could be implemented easier than polling camera position every timestep and switching visibility. I already got some good results with a Quadtree for a city DLL with 10000 buildings and a LOD mechanism reducing vertex count from 800 to 10 - but for one order of magnitude more buildings the calculations of the camera distance and handling the LOD decision took more time than the reduction in rendering time.

If this would already be handled inside Orbiter, it could be done a fair bit faster. Also it would be a good candidate for a parallel algorithm.

Quote:
Originally Posted by martins View Post
 It would also allow to place buildings in areas without bases. The base definitions would essentially become purely logical entities (e.g. to place markers in a map) without any physical assets.
Well, I would then maybe request a API to query base configuration properties and maybe also define additional parameters. For example for letting buildings know the properties of the base they are assigned to.

Quote:
Originally Posted by martins View Post
 So a single DLL for the entire base probably wouldn't work with this interface. The DLL interface would probably be on a per-building-type basis, similar to the current vessel-type DLL structure.
Well, as I know the community, it would only take seconds until the first one tries to have 100,000 building instances of a single DLL at once.... I can see some performance issues there (Oh the memories, when booster separation was performed every timestep). Maybe its necessary to allow buildings to be dormant and don't get any callback calls.
Urwumpe is offline   Reply With Quote
Thanked by:
Old 10-11-2017, 06:42 PM   #423
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
Out of experience I'd say that save/load, time-step and recorder callbacks would also be necessary.
I absolutely second this. If the meshes are subject to LOD, the clbkVisualDestroyed and Created might also be necessary.
Panels might be worth thinking about... I'm not sure they would be strictly necessary, but I'm pretty sure somebody will ask for them 2 seconds after release...

Quote:
If so, I think the placement definition should really be clever to make it easy.
I think long/lat and rotation as a simple angle would be sufficient, or am I missing something?

Quote:
So a single DLL for the entire base probably wouldn't work with this interface. The DLL interface would probably be on a per-building-type basis, similar to the current vessel-type DLL structure.
I can see where you're coming from, but I think there should at least be a logical association possible between buildings. I can easily imagine that being able to query a group of buildings that are part of the same base will be very handy if people want to go a bit more complex with the behavior of their bases.

Last edited by jedidia; 10-11-2017 at 06:46 PM.
jedidia is online now   Reply With Quote
Old 10-11-2017, 08:00 PM   #424
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by jedidia View Post
 I think long/lat and rotation as a simple angle would be sufficient, or am I missing something?
Doing precise layouts with polar coordinates is cumbersome. It is easier to do it in cartesian coordinates in meters. In addition, what about the height above ground? Should it simply snap to the terrain?

All I can say is that I had a hard time getting all this right in AU, so I think getting the coordinate system right is key to easy use. Especially if it is inside the quadtree data structure, which is complicated in itself already.
Face is offline   Reply With Quote
Thanked by:
Old 10-11-2017, 10:55 PM   #425
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
Doing precise layouts with polar coordinates is cumbersome.
I see... hadn't thought of that. Might be another argument for associating buildings with a marker. Define marker position in lat/long, define buildings in local coordinates around markers.

Quote:
In addition, what about the height above ground? Should it simply snap to the terrain?
I would assume so. You can still offset the mesh if you need something levitating for some weird reason...

Quote:
All I can say is that I had a hard time getting all this right in AU
Ah hell, yeah, I can imagine that!
jedidia is online now   Reply With Quote
Old 10-12-2017, 08:40 AM   #426
4throck
Enthusiast !
 
4throck's Avatar
Default

I'd prefer complete Orbiter Script support with working landing points and LUA real-time keyboard input.
That would be useful for many developers.

I don't see anyone drawing individual buildings over large areas by typing coordinates.
And if you are into atmospheric flight, you can use FlightGear. It has OSM buildings and roads....

But of course, anyone is free to spend their free time developing what they wish
4throck is offline   Reply With Quote
Thanked by:
Old 10-12-2017, 06:21 PM   #427
kuddel
Donator
Default 3D9Client (Beta 25.3) for Orbiter BETA r70

Hi,

although there has been no API changes between Orbiter r69 and Orbiter r70, for all who like to be "as current as possible":
Here you'll find the current build of D3D9Client for Orbiter BETA linked against r70.

Have fun,
Kuddel
kuddel is offline   Reply With Quote
Thanked by:
Old 10-13-2017, 03:19 PM   #428
martins
Orbiter Founder
Default

Quote:
Originally Posted by Donamy View Post
 Would that include the rotational errors in the attachments, such as the RMS grapple progression also ?
In the first instance probably yes, since the classes would share a codebase. However, I still want to fix this at the origin. It looks like the rounding errors of the explicit point transformations simply build up too much over time, so a different mechanism needs to be implemented.

Quote:
Originally Posted by 4throck View Post
 I'd prefer complete Orbiter Script support [...]
Ah yes, good point. Are there any volunteers to implement missing script functions? If it's down to me it might take a bit longer. Maybe we could make it a wikipedia-style support appeal: If everybody implemented just one missing function, we could be done in an hour
martins is offline   Reply With Quote
Thanked by:
Old 10-13-2017, 05:51 PM   #429
TCR_500
Biblical Creationist
Default

Martins: Could you adjust the main loop to look something like this?
Code:
while(!Exit)
{
        TimeLeft = TimeLeft + TimeSpent;
        while(TimeLeft > TimeStep)
        {
                PhysicsTick(TimeStep);
                TimeLeft = TimeLeft - TimeStep;
        }
        ProcessInputs();
        Render();
        TimeSpent = GetTimeSpent();
}
Rather than like this?
Code:
while(!Exit)
{
        PhysicsTick(TimeSpent);
        ProcessInputs();
        Render();
        TimeSpent = GetTimeSpent();
}
It'll allow the time steps to remain constant and real-time while allowing a variable framerate. Users can also use the current selection for fixed time step size to change the "resolution" of the physics.
TCR_500 is offline   Reply With Quote
Old 10-13-2017, 11:48 PM   #430
kuddel
Donator
Default

Quote:
Originally Posted by martins View Post
 If everybody implemented just one missing function, we could be done in an hour
Sure, but I am very unsure how the LUA interface works

Just by looking at Interpreter.h and Interpreter.cpp I guessed some of the "logic":
- I assume that the (int) return value of all those static functions indicate the number of return values.
- The parameters have to be "fetched" by index (1-based).
- return value has to be "pushed".
But how to get "buffer" values is not (yet) clear to me...and when to use 'number' and when 'integer' was just guessing, too.

I arbitrarily chose some OAPI functions that were not present in LUA yet -to get a feeling- and did the following:

Interpreter.h
PHP Code:
    // utility functions
    
static int oapi_rand(lua_State *L);
    static 
int oapi_deflate(lua_State *L);
    static 
int oapi_inflate(lua_State *L);
    static 
int oapi_getcolor(lua_State *L); 
Interpreter.cpp
PHP Code:
void Interpreter::LoadAPI ()
{
    
//...
    
static const struct luaL_reg oapiLib[] = {
        
//...

        // utility functions
        
"rand"oapi_rand },
        { 
"deflate"oapi_deflate },
        { 
"inflate"oapi_inflate },
        { 
"getcolor"oapi_inflate },

        {
NULLNULL}
    };
    
//...
}

//...
// ============================================================================
// utility functions

int Interpreter::oapi_rand(lua_State *L)
{
    
lua_pushnumber(LoapiRand());
    return 
1;
}

//OAPIFUNC DWORD oapiDeflate (const BYTE *ebuf, DWORD nebuf, BYTE *zbuf, DWORD nzbuf);
int Interpreter::oapi_deflate(lua_State *L)
{
    const 
BYTE ebuf NULL// How to get "const BYTE *ebuf"
                              // ???

    
ASSERT_NUMBER(L2);
    
DWORD nebuf lua_tointeger(L2);

    
BYTE zbuf NULL// How to get "BYTE *zbuf"
                        // ???

    
ASSERT_NUMBER(L4);
    
DWORD nzbuf lua_tointeger(L4);

    
lua_pushnumber(LoapiDeflate(ebufnebufzbufnzbuf));
    return 
1;
}

//OAPIFUNC DWORD oapiInflate (const BYTE *zbuf, DWORD nzbuf, BYTE *ebuf, DWORD nebuf);
int Interpreter::oapi_inflate(lua_State *L)
{
    const 
BYTE zbuf NULL// How to get "const BYTE *zbuf"
                              // ???
    
ASSERT_NUMBER(L2);
    
DWORD nzbuf lua_tointeger(L2);

    
BYTE ebuf NULL// How to get "BYTE *ebuf"
                        // ???
    
ASSERT_NUMBER(L4);
    
DWORD nebuf lua_tointeger(L4);

    
lua_pushnumber(LoapiInflate(zbufnzbufebufnebuf));
    return 
1;
}

int Interpreter::oapi_getcolor(lua_State *L)
{
    
ASSERT_NUMBER(L1);
    
DWORD r lua_tointeger(L1);
    
ASSERT_NUMBER(L2);
    
DWORD g lua_tointeger(L2);
    
ASSERT_NUMBER(L3);
    
DWORD b lua_tointeger(L3);
    
lua_pushnumber(LoapiGetColour(rgb));
    return 
1;
}
// ... 
oapiRand() and oapiGetColour() seem to be O.K. (although I have no idea whether this is true and they really work as intended), but oapiDeflate() and oapiInflate() left some serious questions

Can someone point me to a (basic) "howto" for this kind of LUA interfacing?


I've added the changes as ZIP, so it might be easier to compare/merge with the "original" (rev.70) sources

---- EDIT ----
Attachment removed

Last edited by kuddel; 10-15-2017 at 01:51 PM.
kuddel is offline   Reply With Quote
Thanked by:
Old 10-14-2017, 12:21 AM   #431
martins
Orbiter Founder
Default SVN commit #71

New commit #71 is now available. As mentioned, this includes the fix for the PMI computation of docked assemblies, as discussed here and described in Doc/Technotes/composite.pdf. This one is probably mainly for indy91 to test, but other vessel developers might want to make sure that their docked vessels do reasonable things.
martins is offline   Reply With Quote
Old 10-14-2017, 12:25 AM   #432
martins
Orbiter Founder
Default

Quote:
Originally Posted by kuddel View Post
 Can someone point me to a (basic) "howto" for this kind of LUA interfacing?
Hey, thanks for picking this up so quickly! The main documentation for Lua (including the C API) can be found here. With regard to memory buffers for de/inflating, probably the Lua "userdata" construct (which simply encapsulates a memory pointer) would be useful to consider: https://www.lua.org/pil/28.1.html
martins is offline   Reply With Quote
Thanked by:
Old 10-14-2017, 02:17 AM   #433
DaveS
Addon Developer
 
DaveS's Avatar


Default

What about the cloud micro textures issue and VC click area problems identified by GLS in the following project issues, 1329 and 1320?
DaveS is offline   Reply With Quote
Old 10-14-2017, 09:39 PM   #434
kuddel
Donator
Default D3D9Client (Beta 25.4) for Orbiter BETA r71

Hi,

although there has been no API changes between Orbiter r69 and Orbiter r71, for all who like to be "as current as possible":
Here you'll find the current build of D3D9Client for Orbiter BETA linked against r71.

Have fun,
Kuddel

Last edited by kuddel; 10-14-2017 at 09:47 PM.
kuddel is offline   Reply With Quote
Thanked by:
Old 10-14-2017, 09:47 PM   #435
kuddel
Donator
Default

O.K. Now I've got some things done to the LUA code, I would like to ask how would I test the oapi.deflate() & oapi.inflate() functions in Lua?
Testing oapi.rand() & oapi.getcolor() was easy:
Code:
term.out(oapi.rand())
term.out(oapi.getcolor(1,2,3))
but how would a lua script look to test whether oapi.deflate() & oapi.inflate() work?
Something like this "pseudo-code"
Code:
inp = 'Hello World!' // input buffer
pak = '' // packed buffer
out = '' // re-inflated buffer
r1 = oapi.deflate(inp, sizeof(inp), pak, 255)
r2 = oapi.inflate(pak, sizeof(pak), out, 255)
term.out(r1)
term.out(r2)
term.out(in == out)
Please help, 'cause I'm not going to spend much time learning LUA in depth.
When I've managed to get this running I'll try to add further functionality.


@martins: I think LuaMFD hass two files missing (resource.h & LuaMFD.rc).
I took the liberty and re-created them as I think they were
Would be nice if they would be added in the next commit (yours, not mine)


---- EDIT ----
Attachment removed due to post #438

Last edited by kuddel; 10-15-2017 at 01:51 PM.
kuddel is offline   Reply With Quote
Thanked by:
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 05:56 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.