SDK Question Dynamically change planet parameters

[computerex]

Hi. I am not sure how to go about changing the textures on the fly, I am not sure if it is possible, it may be with enough poking. But right now schools are about to start

As for the other parameters, I use the following:

void setmass(OBJHANDLE obj, double m)
{
	_asm
	{
		mov         eax, dword ptr [obj]
		fld         qword ptr [m]
		fstp        qword ptr [eax+10h] 
	}
}

void setsize(OBJHANDLE obj, double s)
{
	_asm
	{
		mov         eax, dword ptr [obj] 
        fld         qword ptr [s] 
		fstp        qword ptr [eax+18h]
	}
}

void setname(OBJHANDLE obj, char * newname)
{
	char * nptr = 0;
	_asm
	{
		mov  ecx, dword ptr [obj]
        mov  edx, dword ptr [ecx+0x1CC]
        mov  [nptr], edx
	}
	strcpy(nptr, newname);
}

 

[eyu100]

Why not just do this?

void setmass(OBJHANDLE obj, double m)
{
    *(double *)(obj + 0x10) = m;
}

void setsize(OBJHANDLE obj, double s)
{
    *(double *)(obj + 0x18) = s;
}

void setname(OBJHANDLE obj, char * newname)
{
    strcpy((char *)(obj + 0x1CC), newname);
}

 

[computerex]

No reason not to :thumbup:

 

[jedidia]

because instead of restarting Orbiter with a new solar system you could simply rename all the planets and move them around.

I'm not too sure though how big the benefits would actually be. You still have to load the new textures, so you'll still have loading time. Restarting a rather large system with coplete lvl 8 textures currently takes about 6 seconds, barely enough to read anything on the splash screen. The biggest problem is the texture pregeneration, which takes an awfull lot of time, but the only way to fix this is to plug an LOD routine into a graphics client or maybe ORULEX (i.e. way outside my abilities. If Artlav feels like it he'll maybe do something along those lines, since the texture generator is his work anyways).

But let's not forget that Orbiter Galaxy is a try to use Orbiter for something it currently isn't designed to do, so there always will be drawbacks, no matter which way you turn it.

 

[eyu100]

I'm not too sure though how big the benefits would actually be. You still have to load the new textures, so you'll still have loading time. Restarting a rather large system with coplete lvl 8 textures currently takes about 6 seconds, barely enough to read anything on the splash screen. The biggest problem is the texture pregeneration, which takes an awfull lot of time, but the only way to fix this is to plug an LOD routine into a graphics client or maybe ORULEX (i.e. way outside my abilities. If Artlav feels like it he'll maybe do something along those lines, since the texture generator is his work anyways).

But let's not forget that Orbiter Galaxy is a try to use Orbiter for something it currently isn't designed to do, so there always will be drawbacks, no matter which way you turn it.

There wouldn't be huge performance benefits; the benefit is in making the transition seem more "natural."

 

[Hartmann]

jupiter is shrinking !!! :lol:

could be a thing like this done ??

[ame="http://www.youtube.com/watch?v=vhMYgq-0cGI"]YouTube- 2010 - Peter Hyams - The Birth Scene[/ame]

 

[jedidia]

There wouldn't be huge performance benefits; the benefit is in making the transition seem more "natural."

I'm not sure if having Orbiter freeze for 6 seconds is more natural than seeing the splash screen for 6 seconds... Initially I thought this could help me reduce the file output, but after thinking it over a bit that's not even true... the System still has to be outputed in order to load it when you start Orbiter next time. And cheating the scenario save to output a different system name could get tricky, unless the global name could be changed at runtime too.

Anyways, this is all a bit moot as long as there can't be planets added or removed, same with textures. And I won't divert developement currently to see if it could be done, I'm too close to release. But if a stable proof of concept comes up, I would most probably implement it in a future version, as long as there are no significant backdraws to it.

 

[eyu100]

I'm not sure if having Orbiter freeze for 6 seconds is more natural than seeing the splash screen for 6 seconds... Initially I thought this could help me reduce the file output, but after thinking it over a bit that's not even true... the System still has to be outputed in order to load it when you start Orbiter next time. And cheating the scenario save to output a different system name could get tricky, unless the global name could be changed at runtime too.

Anyways, this is all a bit moot as long as there can't be planets added or removed, same with textures. And I won't divert developement currently to see if it could be done, I'm too close to release. But if a stable proof of concept comes up, I would most probably implement it in a future version, as long as there are no significant backdraws to it.

Obviously you have to be able to change the textures, but you don't have to add or remove planets... Just include a bunch of unused planets in the scenario, set their mass and size to zero, make their texture really simple, and put them somewhere far, far away so that the player never sees them.

 

[computerex]

Or some really really hackish solution would be to load a whole bunch of planets, and simply make their size something close to zero, then resize as needed. The new LOD scheme would help with this.

 

[jedidia]

I thought about this, but it seems a bit too hackish. Should work, but will reduce framerate and might lead to a bunch of unforeseen trouble...