Render to Framebuffer

[Mauiby de Fug]

Yup, it would be nice to implement multiple light sources at some point in the future. Also environment mapping (for reflections and image-based lighting) and shadows ,which would be what is needed to bring the in-game lighting to photorealistic levels. Until such time, we will still have to suspend our disbelief in a few places and accept some inherent weirdness here and there. Unfortunately, all the above need - beyond good glsl knowledge - changes to the core of how we do rendering and that ramps up the difficulty a lot, Ideally we need a render-to-framebuffer implementatoin. If there are any graphics wizards out there, this is your call, go for it.

Not a graphics wizard by any means, but I'm quite tempted to hack about and see what I can learn.

Every couple of years I attempt to create my own rendering engine with the eventual dream of being able to render a procedural world. I usually get as far as the basic rendering system in OpenGL, which does involve render to framebuffers, multiple light sources, shaders etc, and then run out of steam when it comes to everything else. And then restart a couple of years later. I've got that itch again, and it's coincided with me opening Oolite back up. Things that bug me are the look of the suns and the planets when you get close up. Also the main station's front face being fully lit up when the sun is completely blocked by the planet. The idea of playing around with the graphics whilst not having to worry about everything else is quite tempting. And so I got curious about the source code...

I don't know Objective-C, but I do know both C and Rust, so I should hopefully be able to figure out what's going on. I've managed to successfully follow the instructions to build from source on Windows (a remarkably simple process, which is unusual for Windows!) and now need to refresh my memory on the ins and outs of OpenGL. In the unlikely event that I actually am able to do something useful that could be contributed back, it'd probably be a good idea to know what sort of level to target, especially as GL introduces new ways of doing things in different versions. It wouldn't be much good me implementing something with the latest DSA api and then nobody being able to make use of it. On the other hand, there's still legacy GL in the source code. Would it make sense to target a specific GL version (and if so which? 3.0? 3.3? 4.0? Later?) or just use the earliest possible implementations?

Any other suggestions or tips before I go deeper down the rabbit hole are welcomed!

[another_commander]

I would initially try to go for the lowest OGL version that gets the job done. Having said that, I believe there have been no graphics drivers that can't support at least OpenGL 3.0 published in the last 12 or so years.

[Mauiby de Fug]

Looking through the history on khronos.org, it seems that FBOs were promoted to core in v3.0. So based on that I'll target 3.0. In the event of success I can always list the specific extensions used, in the same way that shader support seems to be queried.

Doxygen is now installed and documentation has been generated. It certainly makes it a little easier to see what links to where!

[Cholmondely]

Are we talking about the possibility of introducing binary stars here?

NB: curious about the name. Was Mauiby de Fug a famous Belgian explorer? Or a cartoon character? Or feudal overlord? Or boon companion of Siger of Brabant?

[Mauiby de Fug]

Are we talking about the possibility of introducing binary stars here?

Not directly, although linked. Rendering to a frame buffer is one of the requirements for environment mapping, which would allow reflections and such as mentioned by a_c. 'Twould also be a requirement if one were to attempt deferred rendering, which is one way to allow multiple light sources to be used (imagine the light from a laser or light emissions from a ship such as exhausts or spotlights being able to illuminate other ships). Or alternatively post-processing effects.

Binary stars is a long way off (as is everything else at the moment)! It is fixed throughout the source code that there is only one light source, which is the sun, and there can only be one sun in a system. Editing this would be possible, although one would need a way to render it. Which is where we begin with framebuffers.

Interestingly the code to detect a relevant GL extension was apparently added by Jens back in 2010 when he was attempting environment cube maps. That he didn't get much further should say a lot about the rendering system used in Oolite - having looked at it now I'd describe it as terrifyingly archaic. The part of me which likes shiny things and to run Arch Linux wants to tear the whole thing down. Which would be a monumental undertaking and also remove one of the best things about Oolite - the very low requirements mean that one can run basic Oolite without many oxps on some very old machines. Hence:

I would initially try to go for the lowest OGL version that gets the job done.

I have an idea of where I want to start. Small steps. If anything comes of it I shall let people know.

________________________________________

NB: curious about the name. Was Mauiby de Fug a famous Belgian explorer? Or a cartoon character? Or feudal overlord? Or boon companion of Siger of Brabant?

See https://bb.oolite.space/viewtopic.php?p=149015#p149015

[Cody]

I'd describe it as terrifyingly archaic.

Nice! And good to see you back, Mauiby!

[Cholmondely]

NB: curious about the name. Was Mauiby de Fug a famous Belgian explorer? Or a cartoon character? Or feudal overlord? Or boon companion of Siger of Brabant?

See https://bb.oolite.space/viewtopic.php?p=149015#p149015

Brilliant! Our first rodent profile for the Species wiki page...

http://wiki.alioth.net/index.php/Species#Fiction

[Mauiby de Fug]

And good to see you back, Mauiby!

Thanks! Don't know if this is a brief fly-by or if I'll stay in orbit for some time. Only time will tell!

In the meantime, I think that I have diverted the drawing to render to a texture and so I see a nice black screen with nothing on it. Next step is to see if I can manage to draw what I want to instead. It's probably been more than 10 years since I last used legacy GL - I'm out of practice!

[Cody]

Fly-by squirrels? Whoosh - there goes another one!

[tsoj]

In the meantime, I think that I have diverted the drawing to render to a texture and so I see a nice black screen with nothing on it. Next step is to see if I can manage to draw what I want to instead. It's probably been more than 10 years since I last used legacy GL - I'm out of practice!

I would be interested to know how far you've got with this.
Yesterday I tried apparently the same thing you described here, and what I got is that some parts of the GUI are rendered to the texture, but none of the 3D stuff. I hoped that everything would just render nicely into the texture, and now I am wondering if the reason it doesn't is because of the direct mode OpenGL that you mentioned. I don't even know if that could work with modern OpenGL to be honest, my knowledge is very limited in this direction.

[Mauiby de Fug]

It sound like you managed to get further than I did. I wasn't ever able to get a full screen quad to display anything useful. I vaguely remember trying to debug it by setting corners of a texture to different colours, and instead only getting the upper right quadrant with the colour of a different corner and everything else black. That was when I went wandering around to see what was going on with the matrices and gave up. (I don't think I have a copy of what I'd changed - as I didn't get anything productive I don't believe I saved it anywhere...) Although I don't think I ever tried actually getting Oolite to tell me what the current state was - that might have been a sensible idea!

It's interesting that you managed to get the GUI working but not anything else.

I'm a lot more familiar with the code base now though; I've spent more time just looking at it and tracking things through. Maybe it'd be worth having another shot. What I'd be more inclined to do instead, though, is to try and pick through and update bits of https://www.khronos.org/opengl/wiki/Legacy_OpenGL to work with a modern API. I am aware, however, that this way could lie utter madness.

[tsoj]

Only some of the GUI is rendered. I think it only works when something else is rendered in the background (e.g. the spinning model in the beginning, the whole universe in front of the HUD, the planet on the F7 screen. But these background rendered things also don't show up in the framebuffer texture. It's very weird.

I mean, drawUniverse must render everything into a single framebuffer, so that after calling SDL_GL_SwapBuffers it actually shows up on the screen. Then I don't understand why when I redirect all of this into my custom framebuffer + texture, why it doesn't show up?

Maybe it has something to do with wrong depth buffer or texture format?
Maybe it's because glBegin, glEnd don't render in custom framebuffers? Could also be an OpenGL driver bug. I already found some really strange behavior on my machine, namely that the default framebuffer (i.e. the "screen framebuffer") is not index by 0, but by 1. Took me hours to find.

[another_commander]

Posting here to hopefully alleviate some off-topicness from the introductions thread:

@tsoj, have you seen this post from stackoverflow? https://stackoverflow.com/questions/732 ... draw-to-it
It may contain hints about your issue with the 3d part not rendering at all. Check out the best answer on that page; it seems to me, based on the code snippets I've seen in the introductions thread, that there might be someting related going on.

[tsoj]

I found the issue! I had to be very careful with setting each OpenGL binding (active texture, texture binding, program binding, etc.) back to the original value, after I use these OpenGL functions myself.

As far as I can see, everything works nicely. I just have to clean up the code a bit, and then we'll have a simple prototype for rendering to textures.

EDIT: Apparently it still isn't perfect. While most things render normally, there are some weird artifacts with the skybox and HUD elements/MFDs.

[another_commander]

Great stuff! Does it work OK also if you set the framebuffer format to floating point like this?
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA16F, width, height, 0, GL_RGBA, GL_FLOAT, NULL);

We need this for HDR rendering.