Split: Re-scaling experiment

[Redspear]

The Anaconda as you have it scaled here should, by rights, have around 2,200 TC capacity. I have not run the numbers for the other ships, and assume that fuel needs, etc, scale linearly with volume.

Hi Salisman63.

Please note, the picture you see there shows the mk III at 33% rather than the 50% I have used (actually, the mk III is at 100% and the anaconda at 200% but proportionally it's the same).

So assuming your calculations based on my picture above are correct, we can readjust for a mk III as it appears in the game (c.f. mk III with python pic above).

0.33 x 0.33 x 0.33 = 0.036 (proportional volume at 33%)
0.5 x 0.5 x 0.5 = 0.125 (proportional volume at 50%)

If anaconda can house an estimated 2, 200 compared to a baseline mk III at 33%, then compared to one at 50%...

2,200 x 0.036 = 79.2 (anacondas proportional capacity in the standard game)
79.2 ÷ 0.125 = 633.6 (anacondas proportional capacity in this experimental build)

So (if my maths is correct), not quite the 750 capacity that we actually have but a darn sight closer than either the triple capacity of 2,200 you mention or the just over one tenth capacity of the standard game @ 79.2 .

If you want to scale the Thargon down without making it much harder to fight, you could either make it "Softer" so that it takes less energy to destroy, or weaken its firepower a bit. Possibly a bit of both. (Still harder to kill, but the need would not be quite as urgent. Much more mosquito than falcon, but still a threat when swarming)

Yes, I've mentioned similar with regards to the fighters upthread a couple of times. I prefer making them more fragile generally. In this build they are unchanged.

As for windows builds, I thought that's what I did?
Can only the devs access a pull request?

[another_commander]

(I've never had good luck getting a working compile system running on Windows [snip])

Have you tried the instructions mentioned here? They are pretty straightforward and have worked for a lot of people in the past. In any case, here is a Windows 64-bit build of the Rescaling Experiment as it currently stands: https://drive.google.com/open?id=1dEjeH ... 77z4gxLxQp

As for windows builds, I thought that's what I did?
Can only the devs access a pull request?

What you did is a pull request, which is not the same as a Windows build. Pull requests are not automatically built by us. They are, however, accessible to everyone and not just the developers. You can generate a diff file containing the pull request's changes by appending the .diff suffix in the link that points to the pull request (in this case it would be https://github.com/OoliteProject/oolite/pull/287.diff) and then copy the raw file displayed to a text editor. After that, it is just a matter of applying the patch using the patch utility (already supplied with the build environment for Windows).

[Sailsman63]

@redspear: Gaaa... That's what I get for doing math when I'm tired. I didn't notice that I was using the wrong proportions. Let's give it another go:

Cobra III at normal scale fits in a rectangular prism 130 x 30 x 65 = 250,000 cubic units, approx.
Anaconda at double scale fits in a prism 150 x 120 x 340 = 6,100,000 cubic units.

Assume that the hull is a pyramid, with the base at the backplate, and the back plate covers about 1/2 of the area of the cube's back face, and we get:

Cobbie: 42,250 cubic units
Anaconda: 1,020,000 cubic units (24.14 times bigger)

cobbie cargo capacity of 20 X 24.14 = 483 TC if Anaconda has similar ratio of cargo:engineering stuff. Seems that engines, etc get more space efficient as size goes up, which makes a lot of sense to me.


@another_commander: I have not seen that pre-built environment. May have to try it. With everything being self contained, I could just drop the whole thing on my spare hard drive, rather than trying to shoehorn the posix libs into their normal installed locations. (I still think that its bizarre that the best way to build cross-platform software for windows on windows is to install a mini unix environment that then cross-compiles back to windows. )

[Redspear]

@redspear: Gaaa... That's what I get for doing math when I'm tired.

Easily done

cobbie cargo capacity of 20 X 24.14 = 483 TC if Anaconda has similar ratio of cargo:engineering stuff. Seems that engines, etc get more space efficient as size goes up, which makes a lot of sense to me.

Again, better than 2,200 given the anaconda's specialist role and supposedly superior loading facilities.
It gets more complicated of course as a mk III of the same dimensions can also house 35 TC with a large cargo bay = 35 x 24.14 = 844.9 TC for the anaconda (close enough).

If any proportions appear to make less mathematical sense than in the standard game then I'd be very interested to hear about them . Thanks for sharing your calculations

What you did is a pull request, which is not the same as a Windows build.

Part of the problem is that I just don't know the language of github
Thanks for your help.

[pleiadian]

I have to dig this one up from the graves to come in with a rather hefty question... I'm just interested in the reactions or if it can be done at all. Maybe one step at a time.

Now I'm pretty hooked on Elite Dangerous and the technology behind it. As a programmer, I'm fascinated by how they pulled it off. I'm particularly talking about the actual 1:1 scale in the game. Everything you see is the correct size. No shortcuts there.

Would be possible to re-scale Oolite in such a way also? Like real planets, stars, etc. Obviously there are tricks in perspective to achieve that... but from what I can tell so far in ED, I think the camera clip is turned off and it renders as far as your eye would be able to see, and technically speaking, in OpenGL you could do that. If, say, 1 unit of distance is declared as one AU, objects now can have a much better approximated size. Torus drive can have a much better faster-than-light velocity.

I didn't study the code enough to answer this question myself... so I guess what I'm wondering is, if Oolite's core could be modified to have real-world sizes? Or is that thought just stardust?

[cim]

I didn't study the code enough to answer this question myself... so I guess what I'm wondering is, if Oolite's core could be modified to have real-world sizes? Or is that thought just stardust?

Yes and no. The engine does support larger planets and stars - I put together an OXP a while ago which uses them - but not necessarily particularly well.

You would have noticeable "corners" on the planets at 'real-world' sizes, as a 20,000 triangle polygon gets too large. You can already see these if you go as low as you can on a planet and look at the horizon. Similarly, the way planet texturing works would need to be significantly changed to avoid pixels tens of kilometres wide. There are display issues with large stars at high distances. There's a bit of a hack in the display code to avoid the worst of it, but there can still be strange issues with which objects are displayed in front of which. (You would probably need a higher Open GL version to solve these, which may or may not be practical to hide behind a graphics setting toggle)

The torus drive model also has difficulties with travel in realistic system scales - you end up having significant trouble getting speed curves that both allow decent speed travel between planets and also give fine enough control for moving around a planet. More of a problem is having to control thousands of NPCs across the system on the off-chance that the player goes near them ... and you'd need NPC torus drive too. Some sort of in-system hyperspace jumps which only populate the nearby area might be a better solution.

[jackiebean]

well, technically from a modeling perspective, the planets can be supersized, but then it would have to have a lot more subentities to pull it off and a lot of testing to make sure the planets and stars assemble correctly. that would help alleviate some of the issues for texturing and sizes, but not all. i am not sure if planets and stars are smoothed at all but that can help polygonization on cloaser approach. the texturing is the biggies, how to get it seamless if the planet globe is broken itno sectors and then reassembled by the game? that is a tough one. i imagine they would have to be hand drawn/painted in blender or another program on a high end computer and then rendered out to each their own section. that is the tricky thing. i have been trying to get the paint function working in blender for a while but to no avail, it seems i am missing integral brushes (basically just texture samples) and instructions on how to put those in the right place so they show up in blender are not very easy to find or follow.

anyway from the scripting side i can see where it would throw a monkey wrench into the works and basically you are talking about a whole rewrite of the code that handles just about every aspect of the game. everything is effected by the placement of planets and how large they are.

[Commander_X]

One thing I encountered that might help in addressing some of these issues could be found here ("Logarithmic depth buffer" among three.js examples, which "handles all but the smallest objects with ease").

The details on approach part are usually addressed by LODs (level of details) that prepare the meshes/textures for a specific "size" they are supposed to be presented as, when looked at through the camera. I'd guess this would require quite some re-writing in Oolite's case (mainly considering the game doesn't really have what is called nowadays a "game engine").

[jackiebean]

yes LOD would help. but as you mentioned it would take a major rewrite, since LOD assumes there are at least 3 or more models for each body represented depending on the distance viewed. so there would need to be a new model or set of models the game would call depending on how close one was to it. im sure the actual scripting lines would not be that long, but being as it would require each celestial body would have to have them added, that is no small task. with planets it can potentially be more than three models depending on the size. in some older games this is more noticeable in the transition between models. there are other things to consider. bloom, etc. but those are on the rendering end and have more to do with particle effects or planetary haze, or the atmospheric glow around a planet.

perhaps one way to think of it maybe would be to use both z-buffer and logarithmic depth buffer depending on distance. but that is a lot more lines of code. is that even possible? i like how they did the example on that page, and i was just awed by how large 120,000 light years looks in comparison to a planet or even a moon. then came the 100,000,000!?! it is pretty impressive what LDB can do.

[pleiadian]

One thing I encountered that might help in addressing some of these issues could be found here

[...]

That's quite impressive, considering this is running in a browser. Unbelievable at which scales, small or ludricously large (100 million LY), this small bit of code works.

[cim]

Planets already have LOD on the model - switch to wireframe display mode and view them close up and far away - but there would be serious limitations on continuing that approach any further than it already has been.

[Commander_X]

Planets already have LOD on the model [...]

To be honest, I suspected as much, without consulting the source code, or even checking in wireframe mode. The atmospheric flight I think is where it is mostly visible/used, right?

[Redspear]

IIRC planets in the default game are approx 100 times too small (to be realistic).
To appear 100 times larger we don't strictly have to make them 100 times bigger however...

I've made them 3.3 and 6.6 times bigger without any major problems and I've made ships 3 times smaller.
6.6 x 3 = 9.9 = planets that appear approx 10 times too small rather than 100.
An adder could still scoop and function normally at that size suggesting that a cobra 3 (player default ship) could be sized smaller than aone third it's standard size.

Suppose planets 10 times bigger (than default) and cobra III 6 times smaller...
10 x 6 = 60% of realistic size.

True 6 times smaller is a huge change but then the default Mk III is massive and would remain sizable at approx 32/15/75ft

Could planets (and therefore distances) be made, say 16 times larger rather than 100 and avoid the major cosmetic and torus related issues mentioned above?
(16 x 6 = 96%)

I'm not sure full scale is particularly appealing to me but we may be able to 'simulate' it much better than we can replicate it.

[jackiebean]

is there any way to just do that by OXP instead of a major game change? i for one am ok with the current planet scale, however i do like some of the new screens from the 1.87 development version. really good looking effects. some of the best i have seen in a game. those viper trails really pop. not so sure about the green laser bloom effect but that is a still shot and may not represent the actual experience. anyway about those planet shots (what i can see from the screens in the screen thread) they look pretty good in the development version. better than they did even a year ago. if upscaling doesnt alter the overal ambience that is shown there, then it might be something to look into for release, but then again as an OXP, it might be another route. just sayin.

[phkb]

is there any way to just do that by OXP instead of a major game change?

The planet rescaling requires some code changes at the moment. It is hoped that we can eventually get the changes implemented in a way that the rescaling experiment might be OXPable, but we're not there yet.

those viper trails really pop. not so sure about the green laser bloom effect but that is a still shot and may not represent the actual experience.

a_c might have been using reshade for some of those screenshots, because there aren't any changes to the engine trails or laser effects in trunk (that I know of!).

anyway about those planet shots (what i can see from the screens in the screen thread) they look pretty good in the development version.

You can get the 1.87 change for planet diffuse lighting into 1.86 if you want. Edit the "Shaders/oolite-default-planet.fragment" file, and change line 232 from this:

Code: Select all

	vec3 diffuseLight = diffuseIntensity * DIFFUSE_LIGHT;

to this

Code: Select all

	vec3 diffuseLight = diffuseIntensity * (DIFFUSE_LIGHT * max(0.0, dot(normal, light1Vector)) + AMBIENT_LIGHT);