search

OoliteProject / oolite

The main Oolite repository.
https://www.oolite.space
556 stars 71 forks source link

re-enable NEW_PLANETS and improve planet shaders #28

Open submersibletoaster opened 11 years ago

submersibletoaster commented 11 years ago

Over a year ago this was working quite well, though not stable enough for release. One obvious problem being that support for planetinfo.plist "texture" cube-maps is broken with NEW_PLANETS enabled.

cim-- commented 11 years ago

I've re-enabled NEW_PLANETS in the branch "reenable-new-planets" starting 3c81a70c7 I've managed to get it to load cube maps, and display them correctly, but only with shaders off (which of course loses most of the benefits of NEW_PLANETS) - the shader files need editing for the OOSTD_DIFFUSE_MAP_IS_CUBE_MAP case, but I have no idea where to even start on that.

With cubemaps being the preferred texture format, it probably doesn't make sense to merge that branch back into master until they work with shaders on.

submersibletoaster commented 11 years ago

Thanks cim-- , I will take this and try to get it up and running.

Goals.

cim-- commented 10 years ago

Ah! I figured out what I did wrong with cube maps. So NEW_PLANETS now works mostly as well as the original planets did. The only catch is that the shader is a little inefficient when more than just the diffuse map is included, so if I don't have a planet OXP installed, my frame rate drops horribly when looking at the planet.

Also, the reenable-new-planets branch is massively out of date compared with master - it doesn't even have high-precision coordinates - so what I'd like to do is delete that branch and upload a current one. Is that going to break anything you've done?

Zireael07 commented 10 years ago

shrug cim, you can try doing it and prodding @submersibletoaster a bit when it's more up-to-date

cim-- commented 10 years ago

The current reenable-new-planets branch - I did the delete and update a while back - works relatively well (though only with the "new planets" code which has been around a while), but the catch is that the need to send two large textures to the graphics card isn't great on lower-spec graphics cards (which can nevertheless run 1.77 at full settings).

Probably what we need is a greater range of detail settings for the graphics.

submersibletoaster commented 10 years ago

Sorry cim - I've been barely keeping track of 'Progress' . Today I think I have that branch working similarly to how it was over a year ago from SVN.

Should I push back into reenable-new-planets ?

cim-- commented 10 years ago

Yes, go for it.

submersibletoaster commented 10 years ago

pushed back to the git-hub branch. See also - updated http://swarm.perlide.org/static/shady-planets-test.oxp.zip

NEW_PLANETS , NEW_ATMOSPHERE and PERLIN_3D all enabled , plus my original shader bits

It's all still full of OOLog(@"submersible" .... ) noise.

I did experience some segfaults, when caught with gdb they seemed unrelated.

Program received signal SIGSEGV, Segmentation fault.
0xb7b5b19c in ?? () from /usr/lib/libgnustep-base.so.1.22
(gdb) backtrace
 0  0xb7b5b19c in ?? () from /usr/lib/libgnustep-base.so.1.22
 1  0xb50f9176 in ?? () from /usr/lib/i386-linux-gnu/libffi.so.6
 2  0xb50f9416 in ?? () from /usr/lib/i386-linux-gnu/libffi.so.6
 3  0x082178bd in JSObjectFromNSDictionary (context=0x919a078,
    dictionary=0xa32e208) at src/Core/Scripting/OOJavaScriptEngine.m:1296
 4  0x08217b8a in JSNewNSDictionaryValue (context=0x919a078,
    dictionary=0xa32e208, value=0xbfffb6e8)
    at src/Core/Scripting/OOJavaScriptEngine.m:1349
 5  0x08219c5e in -[NSDictionary(OOJavaScriptConversion)
oo:jsValueInContext:]
    (self=0xa32e208, _cmd=0x88ea1f8, context=0x919a078)
    at src/Core/Scripting/OOJavaScriptEngine.m:1893
 6  0x0823f06f in OOJSValueFromNativeObject (context=0x919a078,
    object=0xa32e208) at src/Core/Scripting/OOJavaScriptEngine.h:240
 7  0x0824e10a in ShipRequestDockingInstructions (context=0x919a078,
argc=0,
    vp=0xac6fe158) at src/Core/Scripting/OOJSShip.m:3384
 8  0x083ebe6a in js::CallJSNative (cx=0x919a078,
    native=0x824dfe6 <ShipRequestDockingInstructions>, argc=0,
vp=0xac6fe158)
    at ../jscntxtinlines.h:701
 9  0x085f5ee3 in js::Interpret (cx=0x919a078, entryFrame=0xac6fe118,
    inlineCallCount=0, interpMode=JSINTERP_NORMAL) at ../jsinterp.cpp:4799
 10 0x083e8015 in js::RunScript (cx=0x919a078, script=0x9834618,
fp=0xac6fe118)
    at ../jsinterp.cpp:653
 11 0x083e8511 in js::Invoke (cx=0x919a078, argsRef=..., flags=0)
---Type <return> to continue, or q <return> to quit---
    at ../jsinterp.cpp:740
 12 0x083c297c in js_fun_call (cx=0x919a078, argc=0, vp=0xac6fe0f0)
    at ../jsfun.cpp:2143
 13 0x083ebe6a in js::CallJSNative (cx=0x919a078,
    native=0x83c278d <js_fun_call(JSContext*, unsigned int, js::Value*)>,
    argc=1, vp=0xac6fe0f0) at ../jscntxtinlines.h:701
 14 0x085f5ee3 in js::Interpret (cx=0x919a078, entryFrame=0xac6fe0b8,
    inlineCallCount=0, interpMode=JSINTERP_NORMAL) at ../jsinterp.cpp:4799
 15 0x083e8015 in js::RunScript (cx=0x919a078, script=0x9825c08,
fp=0xac6fe0b8)
    at ../jsinterp.cpp:653
 16 0x083e8511 in js::Invoke (cx=0x919a078, argsRef=..., flags=0)
    at ../jsinterp.cpp:740
 17 0x083c297c in js_fun_call (cx=0x919a078, argc=0, vp=0xac6fe090)
    at ../jsfun.cpp:2143
 18 0x083ebe6a in js::CallJSNative (cx=0x919a078,
    native=0x83c278d <js_fun_call(JSContext*, unsigned int, js::Value*)>,
    argc=1, vp=0xac6fe090) at ../jscntxtinlines.h:701
 19 0x085f5ee3 in js::Interpret (cx=0x919a078, entryFrame=0xac6fe060,
    inlineCallCount=0, interpMode=JSINTERP_NORMAL) at ../jsinterp.cpp:4799
 20 0x083e8015 in js::RunScript (cx=0x919a078, script=0x916fc10,
fp=0xac6fe060)
    at ../jsinterp.cpp:653
 21 0x083e8511 in js::Invoke (cx=0x919a078, argsRef=..., flags=0)
    at ../jsinterp.cpp:740
---Type <return> to continue, or q <return> to quit---
 22 0x083c2eb7 in js::CallOrConstructBoundFunction (cx=0x919a078, argc=0,
    vp=0xac6fe020) at ../jsfun.cpp:2320
 23 0x083ebe6a in js::CallJSNative (cx=0x919a078,
    native=0x83c2cb1 <js::CallOrConstructBoundFunction(JSContext*, unsigned
int, js::Value*)>, argc=0, vp=0xac6fe020) at ../jscntxtinlines.h:701
 24 0x083e8323 in js::Invoke (cx=0x919a078, argsRef=..., flags=0)
    at ../jsinterp.cpp:703
 25 0x083e8af1 in js::ExternalInvoke (cx=0x919a078, thisv=..., fval=...,
    argc=0, argv=0x0, rval=0xbfffe3a8) at ../jsinterp.cpp:863
 26 0x0834a15c in JS_CallFunctionValue (cx=0x919a078, obj=0xa29914b0,
    fval=..., argc=0, argv=0x0, rval=0xbfffe3a8) at ../jsapi.cpp:5173
 27 0x0823d719 in -[OOJSScript
callMethod:inContext:withArguments:count:result:] (self=0xbaeaca8,
_cmd=0x889f8e8, methodID=..., context=0x919a078, argv=0x0,
    argc=0, outResult=0xbfffe3a8) at src/Core/Scripting/OOJSScript.m:409
 28 0x0814ca16 in -[ShipEntity
doScriptEvent:inContext:withArguments:count:] (
    self=0xbabdf78, _cmd=0x889fd70, message=..., context=0x919a078,
argv=0x0,
    argc=0) at src/Core/Entities/ShipEntity.m:13487
 29 0x0814c5ea in -[ShipEntity doScriptEvent:] (self=0xbabdf78,
    _cmd=0x889f578, message=...) at src/Core/Entities/ShipEntity.m:13408
 30 0x08119261 in -[ShipEntity update:] (self=0xbabdf78, _cmd=0x8923b28,
    delta_t=0.016660988330841064) at src/Core/Entities/ShipEntity.m:2543
 31 0x08315cf6 in -[Universe update:] (self=0x90d87b8, _cmd=0x890fe38,
    inDeltaT=0.016660988330841064) at src/Core/Universe.m:6196
---Type <return> to continue, or q <return> to quit---
 32 0x082cfed6 in -[GameController doPerformGameTick] (self=0x8ee2608,
    _cmd=0x890fe30) at src/Core/GameController.m:331
 33 0x082cfdb6 in -[GameController performGameTick:] (self=0x8ee2608,
    _cmd=0x890fe58, sender=0xa779500) at src/Core/GameController.m:309
 34 0xb7a96b07 in ?? () from /usr/lib/libgnustep-base.so.1.22
 35 0xb7b06248 in ?? () from /usr/lib/libgnustep-base.so.1.22
 36 0xb7ad732b in ?? () from /usr/lib/libgnustep-base.so.1.22
 37 0xb7ad3974 in ?? () from /usr/lib/libgnustep-base.so.1.22
 38 0xb7ad46f4 in ?? () from /usr/lib/libgnustep-base.so.1.22
 39 0xb7ad31d3 in ?? () from /usr/lib/libgnustep-base.so.1.22
 40 0x082cfb29 in -[GameController applicationDidFinishLaunching:] (
    self=0x8ee2608, _cmd=0x8911768, notification=0x0)
    at src/Core/GameController.m:264
 41 0x082d4d5b in main (argc=1, argv=0xbfffef24) at src/SDL/main.m:120
(gdb)

On Tue, Dec 31, 2013 at 6:52 AM, cim notifications@github.com wrote:

Yes, go for it.

— Reply to this email directly or view it on GitHubhttps://github.com/OoliteProject/oolite/issues/28#issuecomment-31364544 .

cim-- commented 10 years ago

Segfault looks unrelated - should be fixed in 985abbce

NEW_ATMOSPHERE seems to have trouble when the planet texture is a cube map. Probably the same fix is needed as for the planet shader.

It ends up incredibly slow - even when just displaying a simple texture - on my machine. That might be inefficiency in NEW_ATMOSPHERE, I think, but loading more than one planet texture map also is a problem.

What I'd like to do is merge in everything up to 2eba6bf7 into master (with NEW_PLANETS on and NEW_ATMOSPHERE off) and then set the normal map (which is a little expensive) to require the new "extra detail" graphics setting. That gets us "NEW_PLANETS" as originally set up, means we can stop using the old PlanetEntity.m file, and gives us some benefit in 1.79 now. Then, we can continue with this branch to get the full shader support in.

What do you think?

submersibletoaster commented 10 years ago

NEW_ATMOSPHERE seems to have trouble when the planet texture is a cube map. Probably the same fix is needed as for the planet shader.

That's fixed pipeline needing something like this in the right place in OOPlanetEntityDrawable?

 OOGL(glDisable(GL_TEXTURE_2D));
 OOGL(glEnable(GL_TEXTURE_CUBE_MAP));

It ends up incredibly slow - even when just displaying a simple texture - on my machine. That might be inefficiency in NEW_ATMOSPHERE, I think, but loading more than one planet texture map also is a problem.

PERLIN_3D is noticeably slower to generate the textures. Do you see problems with frame-rate too ?

What I'd like to do is merge in everything up to 2eba6bf into master (with NEW_PLANETS on and NEW_ATMOSPHERE off)... What do you think?

Sounds reasonable. I've had no end of trouble trying to accomodate NEW_ATMOSPHERE.

cim-- commented 10 years ago

Not sure ... the atmosphere texture should be possible to set as an auto-generated lat-long even with a cube-mapped planet.

Yes, definite frame rate problems. I get 60fps with the current planets, whereas I'm down to 30 or so looking at a default planet here. And yes, texture generation is considerably slower - it takes a few seconds to load the planet on the F7 screen.

We can always leave NEW_ATMOSPHERE out for now - the old one is acting a bit better since some of the bugs were fixed.

cim-- commented 10 years ago

Having done a bit more testing, I wonder if the frame rate problem is because texture coordinates are considerably more efficient when using a cube map compared with using a lat-long map (which is handled by the shader as just a 20,000 polygon UV map). With a lat-long map and the old NEW_PLANETS shader I get ~30-40 fps up close, half that if the planet also has a normal map. With a cube map I get a solid 60 fps (though I can't test cube with normal to see what that does)

Cube maps have been supported since OpenGL 1.3, which is a 13-year old standard now, and the oldest standards level in the graphics survey was 1.4, so I wonder if it's worth switching the texture generation to use cube maps in NEW_PLANETS, with lat-long supported solely for legacy OXPs. I have no idea how complicated that would be to do, though - any ideas?

submersibletoaster commented 10 years ago

Since the normal of the sphere can be used as co-ordinates into a cube map sampler , I suspect that is indeed more efficient than computing latlong U,V using trig. Generating a cube normal map however is not something I've been able to do properly, I think this is to do with tangent space normal mapping as it is usually done for UV maps.

The shady-planets-test oxp has a hack shader for Leesti which applies specular, normal and emission mapping - all with cube maps. Could you let me know how these behave for you WRT frame rate?

On Sat, Jan 4, 2014 at 11:19 PM, cim notifications@github.com wrote:

Having done a bit more testing, I wonder if the frame rate problem is because texture coordinates are considerably more efficient when using a cube map compared with using a lat-long map (which is handled by the shader as just a 20,000 polygon UV map). With a lat-long map and the old NEW_PLANETS shader I get ~30-40 fps up close, half that if the planet also has a normal map. With a cube map I get a solid 60 fps (though I can't test cube with normal to see what that does)

Cube maps have been supported since OpenGL 1.3, which is a 13-year old standard now, and the oldest standards level in the graphics survey was 1.4, so I wonder if it's worth switching the texture generation to use cube maps in NEW_PLANETS, with lat-long supported solely for legacy OXPs. I have no idea how complicated that would be to do, though - any ideas?

— Reply to this email directly or view it on GitHubhttps://github.com/OoliteProject/oolite/issues/28#issuecomment-31577269 .

cim-- commented 10 years ago

Leesti (12-15FPS full screen) runs faster than Lave (8FPS full screen), certainly. Neither is great...

On the basic NEW_PLANETS branch I've got open, Lave is about 12 FPS full screen (PLANETS, ATMOSPHERES, but not PERLIN_3D) with the generated texture; 30 FPS with a Povray cube map.

cim-- commented 10 years ago

NEW_PLANETS is now enabled in master, so I've retitled this issue to track the work after that being done on shady-planets

submersibletoaster commented 10 years ago

no worries. I think the Trader AI warning is just because the gdb was stopped in ShipRequestDockingInstructions for a while. I echoed submersible into latest log as a placeholder.

____submersible____
.javaScript.timeLimit]: ***** ERROR: Script "Oolite Trader AI" ran for 39.0745 seconds and has been terminated.
08:41:30.297 [script.javaScript.stackTrace]:  0 (oolite-priorityai.js:416) <anonymous function>
08:41:30.297 [script.javaScript.stackTrace]:     this: {...}
08:41:30.297 [script.javaScript.stackTrace]:  1 (oolite-priorityai.js:4721) <anonymous function>
08:41:30.297 [script.javaScript.stackTrace]:     this: {...}
08:41:30.297 [script.javaScript.stackTrace]:     sender: [Station "Icosahedron Station" "Icosahedron Station" pos
ition: (63412.4, -15151.1, 345475) scanClass: CLASS_STATION status: STATUS_ACTIVE]
08:41:30.297 [script.javaScript.stackTrace]:     message: "Docking systems active. Welcome to Zaonce."
08:41:30.297 [script.javaScript.stackTrace]:  2 (oolite-priorityai.js:2758) <anonymous function>
08:41:30.297 [script.javaScript.stackTrace]:     this: {...}
08:41:30.297 [script.javaScript.stackTrace]:     handlers: {...}
08:41:30.297 [script.javaScript.stackTrace]:     station: [Station "Icosahedron Station" "Icosahedron Station" po
sition: (63412.4, -15151.1, 345475) scanClass: CLASS_STATION status: STATUS_ACTIVE]
08:41:30.298 [script.javaScript.stackTrace]:  3 (oolite-priorityai.js:225) _reconsider()
08:41:30.298 [script.javaScript.stackTrace]:     this: {...}
08:41:30.298 [script.javaScript.stackTrace]:     newBehaviour: function
08:41:30.298 [script.javaScript.stackTrace]:  4 (oolite-priorityai.js:76) _handlerAIAwoken()
08:41:30.298 [script.javaScript.stackTrace]:     this: {...}
08:41:30.298 [submersible]: docking instructions == {"ai_message" = APPROACH; destination = {x = "66293.92378737118"; y = "-13640.74287602611"; z = "350486.8577375407"; }; "docking_stage" = "-1"; "match_rotation" = 0; range = 1000; speed = 260; station = "<StationEntity 0x9f064c0>{\"Icosahedron Station\" \"Icosahedron Station\" position: (63412.4, -15151.1, 345475) scanClass: CLASS_STATION status: STATUS_ACTIVE}"; }
08:41:30.298 [test]: docking_stage
08:41:30.298 [test]: -1
08:41:30.298 [test]: completed
08:41:30.298 [test]: ai_message
08:41:30.298 [test]: APPROACH
08:41:30.298 [test]: completed
08:41:30.298 [test]: match_rotation
08:41:30.298 [test]: 0
08:41:30.298 [test]: completed
08:41:30.298 [test]: speed
08:41:30.298 [test]: 260
08:41:30.298 [test]: completed
08:41:30.298 [test]: destination
08:41:30.298 [test]: {x = "66293.92378737118"; y = "-13640.74287602611"; z = "350486.8577375407"; }
08:41:30.298 [test]: x
08:41:30.298 [test]: 66293.92378737118
08:41:30.298 [test]: completed
08:41:30.298 [test]: y
08:41:30.298 [test]: -13640.74287602611
08:41:30.298 [test]: completed
08:41:30.299 [test]: z
08:41:30.299 [test]: 350486.8577375407
08:41:30.299 [test]: completed
08:41:30.299 [test]: completed
08:41:30.299 [test]: range
08:41:30.299 [test]: 1000
08:41:30.299 [test]: completed
08:41:30.299 [test]: station
08:41:30.299 [test]: <StationEntity 0x9f064c0>{"Icosahedron Station" "Icosahedron Station" position: (63412.4, -15151.1, 345475) scanClass: CLASS_STATION status: STATUS_ACTIVE}
Program received signal SIGSEGV, Segmentation fault.
0xb77141f4 in class_respondsToSelector (class_=0x3e8, selector=0xb7db2cf0)
    at /build/buildd/gcc-4.6-4.6.3/src/libobjc/sendmsg.c:372
372 /build/buildd/gcc-4.6-4.6.3/src/libobjc/sendmsg.c: No such file or directory.
(gdb) bt
#0  0xb77141f4 in class_respondsToSelector (class_=0x3e8, selector=0xb7db2cf0)
    at /build/buildd/gcc-4.6-4.6.3/src/libobjc/sendmsg.c:372
#1  0xb7bbb17e in ?? () from /usr/lib/libgnustep-base.so.1.22
#2  0xb51b0176 in ?? () from /usr/lib/i386-linux-gnu/libffi.so.6
#3  0xb51b0416 in ?? () from /usr/lib/i386-linux-gnu/libffi.so.6
#4  0x0822802b in JSObjectFromNSDictionary (context=0xa06d9a0, dictionary=0xa0ac1b0)
    at src/Core/Scripting/OOJavaScriptEngine.m:1304
#5  0x0822833e in JSNewNSDictionaryValue (context=0xa06d9a0, dictionary=0xa0ac1b0, value=0xbfffb6c8)
    at src/Core/Scripting/OOJavaScriptEngine.m:1358
#6  0x0822a412 in -[NSDictionary(OOJavaScriptConversion) oo:jsValueInContext:] (self=0xa0ac1b0, _cmd=0x890d7d8, 
    context=0xa06d9a0) at src/Core/Scripting/OOJavaScriptEngine.m:1902
#7  0x08251e97 in OOJSValueFromNativeObject (context=0xa06d9a0, object=0xa0ac1b0)
    at src/Core/Scripting/OOJavaScriptEngine.h:240
#8  0x082610a6 in ShipRequestDockingInstructions (context=0xa06d9a0, argc=0, vp=0xabfdc158)
    at src/Core/Scripting/OOJSShip.m:3400
#9  0x08403a1a in js::CallJSNative (cx=0xa06d9a0, native=0x8260f24 <ShipRequestDockingInstructions>, argc=0, 
    vp=0xabfdc158) at ../jscntxtinlines.h:701
#10 0x0860da93 in js::Interpret (cx=0xa06d9a0, entryFrame=0xabfdc118, inlineCallCount=0, 
    interpMode=JSINTERP_NORMAL) at ../jsinterp.cpp:4799