Sonic and Sega Retro Message Board: Mobius Engine Project General Discussion - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
Loading News Feed...
 

Mobius Engine Project General Discussion Formerly known as: ITT: Engine Project Proposal Discussion

#76 User is offline Aerosol 

Posted 24 February 2012 - 08:26 PM

  • FML
  • Posts: 6394
  • Joined: 27-April 08
  • Gender:Male
  • Location:New York
  • Project:Sonic (?): Coming summer of 2055...?
So this is going to be a thing, for real now! Awesome!

#77 User is offline Gen 

Posted 24 February 2012 - 09:38 PM

  • This is halloween! This is halloween!
  • Posts: 309
  • Joined: 03-August 06
  • Gender:Male
  • Project:The Mobius Engine
I'll be proposing the following shading architecture:
Instead of using the usual light shaders, that read in a diffuse texture, normal texture, specular texture, emissive texture, and so on (which tends to result in a lot of G-Buffer bloat), a surface shader approach would probably be more beneficial here.

The biggest reason to do this, is the decrease lighting shader complexity for deferred rendering.

In a surface shader, you will basically have a handful of surface outputs, such as a diffuse output, a specularity output, an emissive output, and so on.

The shader will basically composite (or write to a buffer) these outputs later on in the rendering pipeline.

After lighting is rendered, for example, you may want to add an emissive effect, or even a sort of edge glow effect.

The kind of setup for this in a surface shader approach, combined with deferred shading, may look something like this:

gl_FragColor = vec4(light.rgb * diffuse + light.a * spec.rgb + emissive.rgb, 0);


Where emissive.rgb may effectively be
emissive.rgb = (1 - dot(view.xyz, normal.xyz)) * glowColor.rgb;
earlier in the shader, and
gl_FragColor = vec4(light.rgb * diffuse + light.a * spec.rgb + emissive.rgb, 0);
may be in a final lighting function that combines all of the outputs in a single effect.

All of this can be easily produced procedurally in a material editor as well.

More complex effects can be added trivially on top of this as well, with virtually zero modification to any of the lighting shaders for deferred rendering. The most that may be needed, is if some kind of diffuse exponent may be needed, in which case it'd be more a matter of slimming the amount of space the normal buffer needs in the G-Buffer (which you can reduce to just the X and Y components, and reconstruct Z in the shaders, and assign the Z component to the diffuse exponent).

EDIT: I can also confirm that energy conserving light reflectance will be implemented. I've already determined a highly optimized normalization function to facilitate it (that only takes a MUL instruction, and a MAD instruction).
This post has been edited by Gen: 24 February 2012 - 10:06 PM

#78 User is online Candescence 

Posted 25 February 2012 - 03:12 AM

  • Posts: 1311
  • Joined: 22-October 10
  • Gender:Male
  • Location:Sydney, Australia
  • Project:Construct stuff
Sounds good!

And two things: 1) holy crap this is actually happening. 2) My name suggestion is WINNING?! WAT.

#79 User is offline Gen 

Posted 25 February 2012 - 03:31 AM

  • This is halloween! This is halloween!
  • Posts: 309
  • Joined: 03-August 06
  • Gender:Male
  • Project:The Mobius Engine

View PostCandescence, on 25 February 2012 - 03:12 AM, said:

Sounds good!

And two things: 1) holy crap this is actually happening. 2) My name suggestion is WINNING?! WAT.

If at least one other ends up tieing with it once voting closes (I'll close the poll on Tuesday, since voting seems to be progressing along at a quick pace), we'll hold a second around of voting using the top three names. Though from the looks of it, Blast Pro will end up winning by then.

#80 User is online Candescence 

Posted 25 February 2012 - 03:50 AM

  • Posts: 1311
  • Joined: 22-October 10
  • Gender:Male
  • Location:Sydney, Australia
  • Project:Construct stuff
Maybe. Mobius Engine and Retro3D are pretty close behind, so it could go either way.

#81 User is offline Aerosol 

Posted 25 February 2012 - 04:05 AM

  • FML
  • Posts: 6394
  • Joined: 27-April 08
  • Gender:Male
  • Location:New York
  • Project:Sonic (?): Coming summer of 2055...?
I honestly wasn't even expecting my name suggestion to pop up. It wasn't even a proper suggestion :specialed:

It's difficult to follow but, can you describe anything else you have in mind for the renderer, Gen?

#82 User is offline Gen 

Posted 25 February 2012 - 06:03 AM

  • This is halloween! This is halloween!
  • Posts: 309
  • Joined: 03-August 06
  • Gender:Male
  • Project:The Mobius Engine

View PostAerosolSP, on 25 February 2012 - 04:05 AM, said:

I honestly wasn't even expecting my name suggestion to pop up. It wasn't even a proper suggestion :specialed:

It's difficult to follow but, can you describe anything else you have in mind for the renderer, Gen?

One thing I intend to implement from the start, is a gamma correct rendering pipeline.

What this basically entails, is reading in diffuse textures (and sometimes specular, ambient occlusion, and some others) as sRGB, writing everything to an sRGB render target, and "correcting" shading along the way (with OpenGL, you basically enable a state called GL_FRAMEBUFFER_SRGB during blending to correct the values output by a pixel shader into the appropriate color space). The benefit to this, is technically more correct shading. That's not to say that many of the tried and true algorithms are "wrong" per se, but more along the lines of most people's monitor gamma *making them* appear incorrect.

This is an old (but still good) article that explains the concept of gamma correction: http://www.cgsd.com/...amma_intro.html
Of course, now days it's more for correcting the results of linear equations to take into account a computer monitor's gamma curve.

There's different ways to implement it. Some use shaders to implement the effect (usually modifying textures as pow(diffuseTex, 2.2); and "correcting" the final fragment color with pow(fragColor, 1.0/2.2); will do the job), though others tend to take advantage of native hardware sampling so to not waste any available instructions on something that can be done "for free" on the hardware.
This post has been edited by Gen: 25 February 2012 - 06:05 AM

#83 User is offline StreakThunderstorm 

Posted 26 February 2012 - 11:08 AM

  • Posts: 141
  • Joined: 10-July 11
  • Gender:Male
  • Project:Mecha Madness
I'm looking forward to this.

#84 User is offline Aerosol 

Posted 26 February 2012 - 11:07 PM

  • FML
  • Posts: 6394
  • Joined: 27-April 08
  • Gender:Male
  • Location:New York
  • Project:Sonic (?): Coming summer of 2055...?
Sounds good Gen. Sounds real good. I'm honestly considering dropping my pursuit of Java and learning a language more conducive to this project to try and help out, though things are quite likely going to go above and beyond my skill level. Even if I did learn C++ quickly enough, I know jack shit about graphics programming and my 3D mathematics leave a lot to be desired!

But really. I want this to come to fruition so badly it hurts. It'd be good for the programmers involved too. Taxman is awesome, but I don't want him to be the only Retro success story!

#85 User is online Candescence 

Posted 26 February 2012 - 11:50 PM

  • Posts: 1311
  • Joined: 22-October 10
  • Gender:Male
  • Location:Sydney, Australia
  • Project:Construct stuff
I myself know some C++, but not THAT much.

Also... Huh. Seems Retro3D as a name is gaining traction. Even though it makes no goddamn sense to me, since this isn't gonna be anywhere near 'retro'. :v:

#86 User is offline Aerosol 

Posted 27 February 2012 - 12:00 AM

  • FML
  • Posts: 6394
  • Joined: 27-April 08
  • Gender:Male
  • Location:New York
  • Project:Sonic (?): Coming summer of 2055...?
Well, the Retro in Retro3D is supposed to reference Sonic Retro itself but don't harp on the names so much. I mean, the engine isn't going to be doing any "Blast Processing" either ;).

#87 User is online Candescence 

Posted 27 February 2012 - 12:54 AM

  • Posts: 1311
  • Joined: 22-October 10
  • Gender:Male
  • Location:Sydney, Australia
  • Project:Construct stuff
Granted, I wasn't really being serious, haha. All of the names kind work in their own ways.

#88 User is offline James K 

Posted 27 February 2012 - 05:40 PM

  • Posts: 30
  • Joined: 16-March 11

View PostGen, on 24 February 2012 - 09:38 PM, said:

EDIT: I can also confirm that energy conserving light reflectance will be implemented. I've already determined a highly optimized normalization function to facilitate it (that only takes a MUL instruction, and a MAD instruction).


You mean this, right?

http://www.rorydrisc...ation-in-games/

No energy conservation:
Posted Image

Fancy energy conservation:
Posted Image

It looks like this basically amounts to more visually correct intensities of light reflecting off shiny(specular) materials. Like the article mentions, it can help make materials created by different designers appear more uniform and visually coherent together, and you've already started implementing it, Gen? Nice!


----------------------

Now Gen, when you mentioned that the hardest part will be creating fallbacks for older hardware, how are you going to handle that? What would be the minimum OpenGL version you plan to support?

There's still a (possibly) large user base that has OpenGL 2.1 hardware with only GLSL 120 support. For example, to make the engine cross compatabtitle with most Mac users, you'd be restricted to writing GLSL 120.

You could always of course, conform to OpenGL 3 by not using fixed function as a fallback for anything, and open an OpenGL 3 context for hardware that supports it.
I'm not exactly sure how much an OpenGL 2.1 implementation with no fixed/depreciated functionality would limit what you want to do with the engine.

I'm pretty sure you want to make it OpenGL 4.1 / OpenGL ES 2.0 compatible, is it possible that you can do that while making the engine work with OpenGL 2.1 too?

#89 User is offline Gen 

Posted 27 February 2012 - 07:09 PM

  • This is halloween! This is halloween!
  • Posts: 309
  • Joined: 03-August 06
  • Gender:Male
  • Project:The Mobius Engine

View PostJames K, on 27 February 2012 - 05:40 PM, said:

View PostGen, on 24 February 2012 - 09:38 PM, said:

EDIT: I can also confirm that energy conserving light reflectance will be implemented. I've already determined a highly optimized normalization function to facilitate it (that only takes a MUL instruction, and a MAD instruction).


You mean this, right?

http://www.rorydrisc...ation-in-games/

No energy conservation:
Posted Image

Fancy energy conservation:
Posted Image

It looks like this basically amounts to more visually correct intensities of light reflecting off shiny(specular) materials. Like the article mentions, it can help make materials created by different designers appear more uniform and visually coherent together, and you've already started implementing it, Gen? Nice!

Basically, yes. I've implemented the slightly more optimized variation that Ruud van Gaal posted later in the comments on that article before. The more accurate one is great and all, but I haven't seen a huge benefit in terms of the accuracy boost to justify the additional ALUs. The less accurate normalization function of (0.0397887357729839 * n + 0.3183) is usually "good enough".

Quote

Now Gen, when you mentioned that the hardest part will be creating fallbacks for older hardware, how are you going to handle that? What would be the minimum OpenGL version you plan to support?

There's still a (possibly) large user base that has OpenGL 2.1 hardware with only GLSL 120 support. For example, to make the engine cross compatabtitle with most Mac users, you'd be restricted to writing GLSL 120.

You could always of course, conform to OpenGL 3 by not using fixed function as a fallback for anything, and open an OpenGL 3 context for hardware that supports it.
I'm not exactly sure how much an OpenGL 2.1 implementation with no fixed/depreciated functionality would limit what you want to do with the engine.

I'm pretty sure you want to make it OpenGL 4.1 / OpenGL ES 2.0 compatible, is it possible that you can do that while making the engine work with OpenGL 2.1 too?

What I'm thinking, is OpenGL 3.x core profile compliant, using a 2.1 context where a 3.2 context just isn't available (I mention 3.2 specifically for Mac support, since that's the highest Apple currently supports as of OS X 10.7; by the time we have something usable, most people will be running 10.7 at the very least anyways).

A 3.2 context would come in handy for a more extended feature set, and would likely be the version that would make use of mixed color formats for the higher precision light buffer (since pretty much all OpenGL 3.x supporting hardware and drivers can do this). Though I doubt that the first few versions of the engine would really take full advantage of a GL 3.x context. It'd mostly be something implemented looking forward (I'm actually trying to decide how best to handle the context creation that'll work across platforms in this way; may resort to SDL or one of the various OpenGL toolkits out there to assist in this).

After looking around a bit, I'm heavily leaning towards using GLM as well as the math library of choice, since it has a lot of functionality built-in, makes no compromises in terms of functionality (it can generate practically any kind of random noise! this comes in handy for soft shadow sampling!), and to top it all off, even provides SSE2 optimized libraries and C++11 support. It also functions a lot like GLSL, and uses many of the same naming conventions (I.e., vec2/3/4, mat4, and so on to define the various vector and matrix types commonly used in 3D programming).

EDIT: Second round of voting has started one hour (EST) early. Our top three were Blast Pro, Mobius, and Retro3D. All three were tied at 14 votes.
This post has been edited by Gen: 27 February 2012 - 11:09 PM

#90 User is offline StreakThunderstorm 

Posted 02 March 2012 - 03:33 PM

  • Posts: 141
  • Joined: 10-July 11
  • Gender:Male
  • Project:Mecha Madness
Implement SSDO and SSGI. Get SMAA in there too, lol.

  • 9 Pages +
  • ◄ First
  • 4
  • 5
  • 6
  • 7
  • 8
  • Last ►
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users