Jengine - OpenGL 3.3/4.x engine & JUI progress

[phibermon]

Hi All,

I've been out of the general loop for quite some time due to personal reasons but I thought I'd give you a little snapshot of the framework/engine (call it what you will) that I've been working on.

"Jengine" (oh how creative) is a fully OpenGL 3.3/4.x 'core' targeted code base that is basically a mash-up of concepts I like from various engines / 3D applications.

So there's no immediate mode people; say goodbye to GLBegin, it's the end for GLEnd, no more ancient fixed function pipeline.

Everything from the UI (JUI for those of you who remember) down to the 3D rendering code is all shader based, utilizing the core profiles of GL3.3/4.x only.

There's no GL2.x/ES code paths for simple reasons : I am but one man. I don't have the time to back-port techniques in the time-frame I'm working to. Plus many techniques including various culling operations are all GPU bound and would require pretty much implementing from scratch all the old CPU methods for such things and finally, I got a new capable graphics card and I do this for my own enjoyment

Ok, here's a screenie of the basic interface, with Terrain, Sky and Camera nodes slapped into the scene-graph :

J - Raster.jpg

The 'Sky' node is capable of various techniques including sky-boxes, domes as well as approximate atmospheric scattering for planetary atmospheres. (still deciding on features here, not sure if I want the engine to render from outer-space so this may be replaced entirely)

The 'Terrain' node is still under development but here you can see a displacement map loaded (height-field) along with textures. Will also supports normal-maps and light-maps in release, but still deciding upon lighting systems to use for the terrain. Anyway, it can page in tiled terrain of theoretically infinite size, what you see here is actually a 32768 x 32768 tiled terrain made up of a single channel 32bit floating point displacment map (for 'Y' resolution) along with a lower resolution tiled diffuse map.

Oh and it uses the latest techniques for tesselation added in GL4.0. Based upon various Nvidia white-papers on the subject, here's a better view of it in operation :

J - Tess Wire.jpg

In the case of GL 3.3, "Jengine" currently just uses a lower resolution mesh than is produced by the tessellation which matches the GL 4.0 performance on my system.

If I end up implementing a classic LOD scheme then I'm not sure what to go for yet.

I'd make the engine exclusively GL4.x but it's pretty much only the tesselation I'm using so far and it seems a shame to cut out so many 3.3 cards just for that.

Anyway, there's tons of other stuff that I won't go into detail about just yet that include : MRT deferred render, full GPU skinning (skeletal animation), Variance Shadow Maps, Physics intergration (currently using newton) as well as all the sandwich fillings like a streaming virtual file system, networking (*anything* in the engine can be serialized) font sub-system, compositing manager for future effects, OpenAL and Path-finding / Steering algorithms (I've ported+improved open-steer) to mention a few.

---

JUI (the windowing interface) has come along in leaps and bounds. Everything or nothing about it can be threaded, it has loads more widgets and also makes use of an FBO rendering mode that in turn allows for full compositing aka compiz on posix systems.

Utilizing FBO's and minimizing re-draws solves many problems, but that's another story

Hope you're all well!

Johnny

[chronozphere]

Those are very exciting developments. Since I have not much time to develop my engine, I might aswell give this one a try when it's more or less finished.

Is it easy to set up and tear down the framework? Would like to see some code examples that show how everything fits together.

[phibermon]

Yes, quite a lot of the engine can be used stand-alone with minimum dependencies, here's some various snippets so you can see the coding style :

Window Initialization

WindowMan := TJWindowMan.Create(JDefaultWindowMan);
WindowStartupProperties := JDefaultWindow;
WindowStartupProperties.FullScreen := false;
WindowStartupProperties.GLMajorVersion := 4;
WindowStartupProperties.GLMinorVersion := 1;
WindowStartupProperties.GLCoreProfile := true;
WindowStartupProperties.GLForwardCompatible := false;

WindowStartupProperties.OnCreate := @OnWindowCreate;
WindowStartupProperties.OnDestroy := @OnWindowDestroy;
WindowStartupProperties.OnExecute := @OnWindowExecute;
WindowStartupProperties.Threaded := false;
JWindow := Windowman.Createwindow(WindowStartupProperties);

Scene & JUI Initialization

Scene := TJScene.create(JWindow.ImageMan,JWindow.ShaderMan, JWindow.ModelMan);
SceneView := TJSceneView.create(JWindow, Scene);

JUIWindowMan := TJUIWindowMan.Create(JWindow);

JUIWindowMan.Theme := TJUITheme.create;
JUIGlobal.WindowMan := JUIWindowMan;

JUIWindowMan.AttachJViewPort(SceneView);
JAPTaskbar := TJAPTaskbar.Create(JUIWindowMan);
JAPSceneTree := TJAPSceneTree.Create(JUIWindowMan, Scene);

Example Render Loop

FCamera.Look;
{Set Shader Uniform buffers}
FJWindow.ShaderMan.ModelViewMatrix := FCamera.ModelViewMatrix;
FJWindow.ShaderMan.ProjectionMatrix := FCamera.ProjectionMatrix;
FJWindow.PrimativeRenderer.Grid(vec3(-128,0,-12);
FScene.DoRender;


-----

You may of noticed that JWindow contains the image, model and shader managers.

While this might seem like an odd design decision it's simple enough : JWindowMan supports multiple windows across multiple monitors that the user might want to have their own resources/contexts. So everything that is specific to the context lives in JWindow. Shared contexts across multiple windows are handled by JWindowMan and you simply tell it which window you want to share with.

[Traveler]

Looks pretty great! Too bad you're aiming for top of the line gfx cards only. I understand your reasoning, but you're targeting a small audience if you're planning to make a game with this engine eventually.

[phibermon]

You are quite right, my reasoning doesn't make for a sound design decision in the present day but :

there will come a day when it's no longer a problem

I want to make an MMORPG so by the time I've finished? all this may very well be old news

I secretly harbor the desire to get lots of developers on board and perhaps open up GL2.x/ES code paths (ok, so not so secret now)

[WILL]

I wonder how compatible this might be on say iOS? Not to sound redundant, but it's the way a lot of developers are going these days.

[Traveler]

I believe iOS still uses GL2.x/ES

[phibermon]

I'm afraid that IOS doesn't interest me enough at the moment. There can be no doubt that IOS with it's staggering user-base is attracting a large number of developers but that's not where the cutting edge of graphics are and that's where I would like to be personally.

If anything IOS is a huge step backwards for developers in terms of GPU technology.

While the mobile platforms have performance characteristics that are very impressive for their size and power footprint, compared to the high end PC spectrum and indeed the soon to be released, next generation consoles?

The IPad 2 for instance, with it's out-of-order, dual core 1gz A9 Cortex chip and PowerVR GPU would barely hold it's own against average gaming PC's of 8 years ago (especially given that the small cache that normally accompanies the A9 implementations; 'ghz to ghz' comparisons against desktop CPUs of similar frequencies are woefully ill-founded)

I feel there's work to be done on the Object Pascal front, targetting the newer versions of OpenGL.

And assuming I continue to work alone? I should be finished right about the time that mobile devices see the next generation of OpenGL ES

My reasoning would be this : major companies have bought into ES fully; Apple, Samsung, Sony etc. They're all now bound to OpenGL (somthing that I bet microsoft is regretting given they've had plenty of opportunity to cross platform DirectX )

When the next itteration of ES comes, that'll be what these companies use and it will almost certainly be a sub-set of GL4.0 or some future version. Khronos will not further diverge ES away from the mainline GL versions, if anything they'll aim to merge again.

But I digress.

Really it's because I want to, I'm not interested in 'following the money' or even targeting the largest audience. If that was my goal I'd be coding in C/C++

[code_glitch]

Ah but on iPad 2 its supposed to be '9x faster' than 'iPad 1' which is 'faster' than iPhone which is 'faster' than... well you get the idea. Overall, looking pretty good. Looks like some very nice performance there (455fps). What card is this running on? My HD4330 only has OpenGl 3.2 so I'm at a loss there, and most GMA cards come with 2.1 or somewhere in that ballpark. And the newest sandy bridge 'cards' shipping on o7s etc only sport OpenGl 3.1/3.2. Unfortunately, i7 is 'the future' according to intel, so yes I agree it will not be an issue with gamers that have a GTX460 (or even casual people like me that buy a mid range discrete card, no debates please, I get >30fps out of almost everything on med settings, will just be on that bandwagon). Just don't make the game too popular k? lol. You might end up getting intel to make real graphic chips one day.

Anyways, I get what you're saying in a sense: if no one uses the latest technology, then why is it there in the first place and why make new things right? Shame no one likes the word 'new'. In programming new = crash, bugs, trouble and more trouble so I can understand some of the reasons. But OGL 1.5 on windows 7 platforms? come on...

[Carver413]

I have to agree with phibermon, it is not very wise to build a new engine on old code.