10 replies to this topic

[COfenberg]

Description
This are screenshots of the deferred renderer of our just released PixelLight 3D engine. (in development since 2002)

PixelLight is an open-source, cross-platform 3D application framework written in C++. It currently supports Windows and Linux, and a mobile port for Maemo 5 is on the way. PixelLight has a highly plugin driven architecture with plugins for many third-party middleware such as sound and physics engines, input devices etc. It has a modern deferred shader renderer and currently supports both OpenGL and OpenGL ES 2.0.

Now to the interesting part, some technical details of what can be seen on the screenshots:
- OpenGL renderer (OpenGL 1.1 + extensions)
- Horizon Based Ambient Occlusion (HBAO)
- HDR rendering with Reinhard tone mapping, automatic light adaptation and bloom
- Gamma correction
- Shadow mapping
- Volumetric light scattering (nearly no visual impact within the shown screenshots) and depth fog
- Material features like diffuse and opacity mapping, normal mapping, parallax mapping, two sided lighting, specular and gloss mapping, emissive mapping, glow mapping, fresnel reflection, environment mapping... just the usual must-have stuff for modern 3D engines nowadays

On www.pixellight.org you'll find some videos, downloadable demos, an SDK for Windows and Linux and of course the URL of our public git repository.

[rouncer]

looks nice!

[astrofra]

The rendering features look very clean.
Is there any tool/exporter/pipeline for artist to work directly with the tool ?

If I want to export some of my nextgen stuff from 3DSMax into your engine, for example ?

[COfenberg]

astrofra said:

The rendering features look very clean.
Is there any tool/exporter/pipeline for artist to work directly with the tool ?

If I want to export some of my nextgen stuff from 3DSMax into your engine, for example ?

There's a PixelLight scene exporter for Autodesk 3ds Max - the dungeon scene was exported using this exporter. On our developer wiki, there are multiple tutorials on how to use this exporter: https://developer.pi..._scene_exporter

There's also a generic example scene that can be used for first experiments:
https://developer.pi...c_example_scene

[Reedbeta]

Cool. Just looking at the feature list, I wonder: did you experiment with different SSAO methods e.g. volumetric obscurance (seems to be the most popular in shipping games lately)? If so, why did you end up choosing horizon SSAO? Also, I've heard complaints about the Reinhard tone mapping operator that it tends to desaturate the dark colors too much compared to a more "filmic" operator - did you find that to be the case?

[COfenberg]

Reedbeta said:

Cool. Just looking at the feature list, I wonder: did you experiment with different SSAO methods e.g. volumetric obscurance (seems to be the most popular in shipping games lately)? If so, why did you end up choosing horizon SSAO?

I've also implemented High Definition Ambient Occlusion (HDAO) as described within the ATI Radeon SDK (http://developer.amd...s/HDAO10.1.zip), but it's looking like edge detection instead of a kind of shadowing. I think HBAO looks quite good, although it eats up a lot of fillrate. Within the PixelLight rendering system, SSAO is implemented as a kind of compositing layer, and therefore it's quite simple to try out other SSAO approaches as well. So, there's no big argument why I've used HBAO within the dungeon demo - it was just one of the tested SSAO techniques which gave good smooth results. "Volumetric Obscurance" looks interesting, I'll put it onto my "check it"-list, thank's for the tip.

Reedbeta said:

Also, I've heard complaints about the Reinhard tone mapping operator that it tends to desaturate the dark colors too much compared to a more "filmic" operator - did you find that to be the case?

I've chosen the Reinhard tone mapping operator because it looked like a popular choice. As for the SSAO, tone mapping is just a compositing plugin within PixelLight and the first one which gave acceptable results - although, yes, I also noticed a desaturation of dark colors, but I think that's not a bad thing for every scene. (especially in the really dark dungeon demo scene it looks nice)

[astrofra]

COfenberg said:

There's a PixelLight scene exporter for Autodesk 3ds Max - the dungeon scene was exported using this exporter. (...)

Ok, I tried it quickly.

It seems stable and rather comprehensive !
However, I was surprised to see that the target must be defined during the export process (meaning one must export twice to be compatible with two different targets?), and no matter the target selected, a DirectX shader must be used within each 3DSMax material.

That last point stopped me, as I NEVER use any of these shaders, because they aren't platform/target agnostic at all :')

Anyway, the whole engine/pipeline looks rather solid (no crash, no export failure ...)

[COfenberg]

astrofra said:

However, I was surprised to see that the target must be defined during the export process (meaning one must export twice to be compatible with two different targets?), and no matter the target selected, a DirectX shader must be used within each 3DSMax material.

I'm sorry, but don't understand what you're meaning with "target". The result of the export are XML files describing material properties and how the scene graph looks like as well as meshes within a binary format and of course the used textures. This data is quite generic and can, in fact, also be used within none PixelLight applications. Within the export dialog there are some special settings like "scene renderer" or ambient color, but those are only hints for the application using this scene.

The DirectX shaders are only optional, so one can get an idea within the 3ds Max viewport how the result will look like. When exporting 3ds Max materials with fx-Shaders - only known settings are exported to the mentioned PixelLight XML material descriptions, so, no shader code is exported. A PixelLight material tells the used scene renderer how the result should look like, but how this result is created, or what kind of provided material information is actually used, is up to the scene renderer which interprets the material descriptions.

The 3ds Max exporter within the SDK comes with a documentation describing what kind of information can be exported and so on.

astrofra said:

Anyway, the whole engine/pipeline looks rather solid (no crash, no export failure ...)

Thank's for the compliment. This pipeline was already successfully used in multiple commercial projects - even within a minimalistic Java3D port of PixelLight. (this exporter was used to export the complete scenes and animations, which then, were used within an Java3D application)

[astrofra]

Oh, OK, sorry. I assumed that the "Scene Renderer" was an export directive regarding the final target (fixed, forward, deferred, ...).

Obviously, I was wrong :)

[Luz Reyes]

Nice work! Are the walls in the second image a 3D wiremesh or just a very good texture map and/or shader? If it's just a shader, wow, how did you get the shadows to change as you move further away from the light source? And it it's a wiremesh, how are you keeping render speeds up?

[COfenberg]

Luz Reyes said:

Nice work! Are the walls in the second image a 3D wiremesh or just a very good texture map and/or shader? If it's just a shader, wow, how did you get the shadows to change as you move further away from the light source? And it it's a wiremesh, how are you keeping render speeds up?

Actually, the walls are 'flat' and just use diffuse, normal, specular, gloss and height maps as nearly every material within this demo. The height maps are used for parallax mapping to fake a 3D effect. The omnidirectional light sources are using traditional depth cube maps for shadow mapping.