A step towards solving the f*&%§d-up distances conundrum

[Eric Walch]

4.
Recode Oolite´s handling of to the player distant objects.. objects you can´t see do not need to be drawn. The stations for example are visible from very far away.. keep only their position/heading/orientation/ and current actions. For distant objects collisions should be handled with simpler calculations... For docking figure something clever..

This one does not belong to the list of to do things, it is already happening.

- When looking at large object of type ship (not planets) you will see them disappear suddenly. Somewhere around the 300 000 m distance. Currently it is only noticeable with the torus stations. Once I made a station of the size bigger than the sun. After adding it behind the sun it wasn't there. Flying towards it, it suddenly was there and filled my whole screen.

- And for collision detection it is best seen with the GRS station: Wait until a ship has docked at the external port. Than fly away and keep the ship in your back view. A little after the station has left your scanner, the ship will explode. That is because at this distance a simplified collision detection takes place. And than everything within the stations collision radius will be interpreted as having collided. (Exception is the z-axis of a station)

And I am very happy with the current distances: It makes Oolite being an Elite clone.

[Frame]

@Eric Walch

Is this any different for the main station then, since I can quite easily see the main station at 412695.2 Oolite Kms. in the G1 Leralace system.. I got that figure from the debug console...

While I'm not having buoy repair installed at the moment, I'm also pretty sure I can see that from any distance. the seedy bar is also noticeable from any distance.

So I just do not see that happening anywhere... a bug ?

[Eric Walch]

So I just do not see that happening anywhere... a bug ?

Look into a test oxp I once made: Large Test Globe. It is far bigger than the sun and placed behind the sun in every system. From the main station you won't see it. Fly towards the sun and it suddenly pops up. Turn around and it disappears again.
Depending on the system it already happens on sun approach or in other systems you must pass the sun before seeing it.
But maybe I remembered the 300 000 meter distance wrong. Currently (since 1.72) Oolite crashes with me when I use a distance calculation in the console (or even write it to the log file)

[Svengali]

Is this any different for the main station then, since I can quite easily see the main station at 412695.2 Oolite Kms. in the G1 Leralace system.. I got that figure from the debug console...
While I'm not having buoy repair installed at the moment, I'm also pretty sure I can see that from any distance. the seedy bar is also noticeable from any distance.

From the main station you won't see it. Fly towards the sun and it suddenly pops up. Turn around and it disappears again.
Depending on the system it already happens on sun approach or in other systems you must pass the sun before seeing it.

I think this is a platform-difference. On my system (Win like Frame) I can see Erics test station at 1279492.5950070336km and all main stations from the WP. That's was one of the reasons to make the GRS station a little bit darker, so it depends now on the angle.

[Frame]

Is this any different for the main station then, since I can quite easily see the main station at 412695.2 Oolite Kms. in the G1 Leralace system.. I got that figure from the debug console...
While I'm not having buoy repair installed at the moment, I'm also pretty sure I can see that from any distance. the seedy bar is also noticeable from any distance.

From the main station you won't see it. Fly towards the sun and it suddenly pops up. Turn around and it disappears again.
Depending on the system it already happens on sun approach or in other systems you must pass the sun before seeing it.

I think this is a platform-difference. On my system (Win like Frame) I can see Erics test station at 1279492.5950070336km and all main stations from the WP. That's was one of the reasons to make the GRS station a little bit darker, so it depends now on the angle.

may haps the win build is buggy... I´ll take a look at the code, and try to find out what is going on... I really do not see something as simple as this should be driver dependant...

[Frame]

To add:

I just noted that an Adder disappeared from showing/Drawing at around 16,000 Oolite meters. So clearly there is some sort of size / distance comparing going on....

Edit: found this

Code: Select all

// Entity.h


#define NO_DRAW_DISTANCE_FACTOR		512.0
#define ABSOLUTE_NO_DRAW_DISTANCE2	(2500.0 * 2500.0 * NO_DRAW_DISTANCE_FACTOR * NO_DRAW_DISTANCE_FACTOR)
// ie. the furthest away thing we can draw is at 1280km (a 2.5km wide object would disappear at that range)

So if we use that to calculate on a normal station of 1000km length and width we get

1000*1000*512*512 = 262144000000

Taking the square root of that results in 512000

So you can se the station from 512,000 Oolite meters away.... which is a bit of an overkill in my opinion given the fact that stations often are within this range when seen from the witch point...

And a test run confirmed, pausing the game at exact 512448.8073699135 Oolite Meters from the main station (lucky pause press), just at the exact moment the station disappeared

Good... Thing. but i´d say we should shave 100 km of that number somehow.. without affecting than for example the adder disappears at an even closer range..

for at least 100 km, that station is nothing but a 4 pixel dot... but how to...
suggestions ?

[drew]

I assumed this 'objects disappearing at a certain distance' thing was PC-spec related. On my big PC objects would stay in view for ages, but on my old laptop things would often disappear before they reached the edge of the scanner (eg. Tori stations)

Cheers,

Drew.

[Eric Walch]

Frame, with the help of your findings if found also, in OOSelfDrawingEntity.m in the function findCollisionRadius that calculates the collision radius of objects:

Code: Select all

	d_squared = (length_longest_axis + length_shortest_axis) * (length_longest_axis + length_shortest_axis) * 0.25; // square of average length
	no_draw_distance = d_squared * NO_DRAW_DISTANCE_FACTOR * NO_DRAW_DISTANCE_FACTOR;	// no longer based on the collision radius

So here the drawing distance is set and in ShipEntity (and also OOSelfDrawingEntity.m) we find:

Code: Select all

- (void)drawEntity:(BOOL)immediate :(BOOL)translucent
{
	NSEnumerator				*subEntityEnum = nil;
	ShipEntity					*subEntity = nil;
	
	if ((no_draw_distance < zero_distance) ||	// Done redundantly to skip subentities
		(cloaking_device_active && randf() > 0.10))
	{
		// Don't draw.
		return;
	}
	
	// Draw self.
	[super drawEntity:immediate :translucent];

When looking further we see that subentities are handled separately with a no draw distance of their own. When the main thing is drawn, it looks further if the subs are big enough to be drawn. And that is were the torus station gets wrong. It has a very small main entity. Probably that stops drawing at a certain distance because the main body (the central axis) becomes to small to see. But the big subs (the rings itself) are than also not drawn.

It looks more of a wrong design of the torus station because the subs are bigger than the main body. Probably a good advise to ship designers: Always make the main body also the biggest to be sure of correct drawing!

When searching I can not see anything hardware specific, but Oolite has in its preferences a check-box for reduced detail. Probably this is used. When off it stops drawing those nice nebulas, but surely also other things.

[Frame]

That is most welcome information Too.

It means that moderls, to a certain extent can make sort of level of detail...

look at this link for level of detail... as url = don't accept parenthesis signs in a link BBcode DOH!!!! then copy and paste the entire line

http://en.wikipedia.org/wiki/Level_of_d ... ogramming)

So if your main model is of a low polygon count, you can stuff all the details you want removed at larger distances into the sub entities...

of course that has to balanced against the models usage and looks...

I think Griff´s Boa could really make some nice use of this... as can I

[Screet]

Look into a test oxp I once made: Large Test Globe. It is far bigger than the sun and placed behind the sun in every system. From the main station you won't see it. Fly towards the sun and it suddenly pops up. Turn around and it disappears again.
Depending on the system it already happens on sun approach or in other systems you must pass the sun before seeing it.

Hmmm, I did not see it at all?!?

Concerning distances and precision, I noticed that sometimes the W buoy is so far away from the planet that the planet is not drawn round, but has noticeable edges, more resembling some sort of big thargoid ship.

If precision of the number system becomes a problem, maybe it's easier not to blow up the number system endlessly, but to create a quadrant system in which each quadrant has it's own precision handling, thus bigger distances would change from one quadrant into another, but should be able to keep their precision...of couse this would require some programming efforts and should not be considered for as long as the current precision is good enough.

Screet

[Frame]

Concerning distances and precision, I noticed that sometimes the W buoy is so far away from the planet that the planet is not drawn round, but has noticeable edges, more resembling some sort of big thargoid ship.

If precision of the number system becomes a problem, maybe it's easier not to blow up the number system endlessly, but to create a quadrant system in which each quadrant has it's own precision handling, thus bigger distances would change from one quadrant into another, but should be able to keep their precision...of couse this would require some programming efforts and should not be considered for as long as the current precision is good enough.

Screet

My point 5 in the an earlier reply in this thread

Design a method to move the internal (OpenGL) coordinate system around the player once he begins to leave the stable range.... while not moving the external coordinate system.
(my solar OXP is using just such a method, where all ships are moved out and in of the stable range coordinates... it affects the non player occupied systems though

This is much smoother than quadrants / sectors, as a converter / translator will take care of what Values the OpenGL uses to draw, which is the the real problem, and what values are used to plot objects in the universe...

OpenGl has fixed type of values named floats... that it uses to draw anything on screen...

Before anymore people starts to talk about precision...

I advise you to read this...

http://steve.hollasch.net/cgindex/coding/ieeefloat.html

to try to understand floats.. and why when the numbers gets larger precision is lesser...

Which is why using one set of coordinates for plotting, and another for drawing in OpenGL will give you better drawing, floats are used for almost anything in OpenGL, texture projections, model projections, etc etc... you cannot get around it by using something else..

The plotting coordinate system is less vulnerable but at every very extreme values and you can even overflow a float, it will run into trouble too...

Cheers Frame...

[Commander McLane]

Just to get back to the thread , I am with Cmdr James here. I jus don't see any issue to be solved. As far as I am concerned, there is no 'f*&%§d-up distances conundrum'.

I also want to raise another issue: Extra stations and many more OXP-related stuff are currently placed according to the distances as they are. If you would blow up the planet 20-fold (or even 10- or 5-fold), it could well just swallow the Link-base from Ionics.oxp, to name just one example of dozens.

So if you don't mind that you destroy virtually all your existing mission OXPs by raising the distances and sizes, feel free and go ahead...

[Lestradae]

Just to get back to the thread , I am with Cmdr James here. I jus don't see any issue to be solved. As far as I am concerned, there is no 'f*&%§d-up distances conundrum'.

That's why I found the idea of an oxp-able "sliding scale" interesting. It would make this aspect of Oolite customisable. And if you like it as it is, period, then you just let the default "1.0" stand as it is.

If you would blow up the planet 20-fold (or even 10- or 5-fold), it could well just swallow the Link-base from Ionics.oxp, to name just one example of dozens.

So if you don't mind that you destroy virtually all your existing mission OXPs by raising the distances and sizes, feel free and go ahead...

A sliding scale would have to keep the original coordinate system in place. So that anything that places something into a specific spot still does that in relation to any other spot, just with a new distance multiplied by the sliding scale value. Problem solved.

All I'm saying is I would like such a feature. I would also like a feature to directly change ship/station/asteroid sizes via shipdata.plist. It all boils down to a) if there are enough other people who want this feature too and b) if one of the devs can be convinced to put it into the trunk.

If it doesn't happen, well, I also like Oolite as it is, with those features I would like it even better

Cheers

L

[Commander McLane]

If you would blow up the planet 20-fold (or even 10- or 5-fold), it could well just swallow the Link-base from Ionics.oxp, to name just one example of dozens.

So if you don't mind that you destroy virtually all your existing mission OXPs by raising the distances and sizes, feel free and go ahead...

A sliding scale would have to keep the original coordinate system in place. So that anything that places something into a specific spot still does that in relation to any other spot, just with a new distance multiplied by the sliding scale value. Problem solved.

Unfortunately it won't be that easy. For a start most objects are currently not placed relative to other objects, but at absolute positions. And it would need a quite sophisticated algorithm to translate the absolute spot into a relative spot and scale it. Not mentioning that a lot of the JS-positioning possibilities need the absolute scale.

On top of that not mentioning that I for instance tend to very carefully design the sets in which the action in my OXPs takes place. I have spent hours with thinking and with trial & error while I was placing everything as I wanted it for certain scenarios of Cataclysm. If all this would be re-scaled relatively, not only the movie-set would be ruined, but parts of the mission could become unplayable.

As I said before: Go ahead with all the change-the-whole-ooniverse ideas. But don't complain afterwards if certain things are not working anymore.

[Lestradae]

If all this would be re-scaled relatively, not only the movie-set would be ruined, but parts of the mission could become unplayable.

Yeah ... you got a point there. That was something I didn't take into account: The visuals. If you "set up a stage" for an oxp situation and the distances are, say, 10 times bigger and the speeds 10 times higher, the optics have changed. And this is an important immersion-element.

Concerning the absolute-relative coordinates topic, that could be solved. You once mentioned (I believe) that someone close to you is a physicist. I am a one-third one, too. So you will know about all those options to create coordinate-invariable vectorspaces. That one could be solved.

But not the cinematics. Hm, as I said, my assumptions sometimes are too naive about how easy (or, as the case may be, not) something new is to be implemented.



L