September 19, 2018, 03:10:07 AM

Author Topic: OpenB3D 1.25 and OB3D Plus  (Read 462 times)

Offline angros47

  • Jr. Member
  • **
  • Posts: 11
OpenB3D 1.25 and OB3D Plus
« on: April 17, 2018, 12:26:45 AM »
New version is online. In this version, some bugs have been fixed, and the code in the shader part has been cleaned a bit. Instead of adding further new features, this time I preferred to introduce a new helper library, named OB3D Plus. The reason is that most of the new features rely on shaders, and until now, I always tried to keep OpenB3D compatible even with older hardware that provided no shader support.

I didn't like to either have to drop support for some hardware, or to keep OpenB3D back, so I preferred to put the new features in a separate library, with different hardware requirements.

The features of OB3D Plus include: High Dynamic Range, Screen Space Ambient Occlusion, Material Capture, Fur Shading, simple Deferred Rendering, Interior Mapping, and more. Also, it allows to save videos of the rendering.

Offline markcwm

  • Sr. Member
  • ****
  • Posts: 292
Re: OpenB3D 1.25 and OB3D Plus
« Reply #1 on: April 18, 2018, 12:57:59 PM »
Hello Angelo and thanks for the new version!

Thanks for keeping the GL3+ stuff in a separate library, I intend to stay with GL2 and also hope to support GL1.

I wonder why you removed the ShaderObject class? This is useful for detach or delete shaders.

Also, I have quite a few fixes for the library now, if you're interested I'll post them.

I'm looking forward to trying out your post processor and anti alias solutions!

Offline angros47

  • Jr. Member
  • **
  • Posts: 11
Re: OpenB3D 1.25 and OB3D Plus
« Reply #2 on: April 18, 2018, 11:31:10 PM »
I removed the ShaderObject class because I noticed that, in the previous version, the features to detach single shaders were actually never called (at least in the vanilla version); also, I was trying to simplify the structure: in the previous version, fragment and vertex shaders were processed in their own subroutines, in the last one, there is just one subroutine for all of them, so adding the geometry shader required very few changes.

What kind of fixed do you have?

Offline markcwm

  • Sr. Member
  • ****
  • Posts: 292
Re: OpenB3D 1.25 and OB3D Plus
« Reply #3 on: April 20, 2018, 09:08:23 PM »
I externed extra shader functions to create, attach, delete (for Krischan to speed up his project) that rely on ShaderObject, so I will have to re-add that class and all the modifications if I want to update.

* Fixed FreeTexture crash (if same texture loaded multiple times)
* Fixed FreeAction crash (crash if action still referenced, new command EndAction helps fix it)
* Fixed MD2 crash on exit bug (needed +1 memory size)
* Added LoadTexture ApplyAlpha and ApplyMask functions (texture flags 2 and 4)
* Fixed Alpha blending render rules for entity or surface (see standard/alphamap)
* Fixed B3D lightmap not loading (tex slot 7 never set)
* Changed FX 1 not using normals data (causing a 2d texture effect)
* Added automatic shader error messages
* Fixed octree.cpp build error on BRL Bmx in Win32 (members near, far renamed)
* Fixed only last collision working with multiple collisions
* Fixed LoadAnimTexture not loading anim image columns (yframes)

Also, I see you changed AddParent from object by reference to pointer, was there any reason for this?

Offline angros47

  • Jr. Member
  • **
  • Posts: 11
Re: OpenB3D 1.25 and OB3D Plus
« Reply #4 on: April 21, 2018, 07:06:36 PM »
Actually, attaching a shader to a program is only useful before the linking phase, and so, if you want to handle the single shader, you would also need to call the linking function... and at this point, you can just use built-in OpenGL function (the purpose of OpenB3D is to simplify, not to make things more complex)

About AddParent, I changed it to align the function with the others (other functions accept pointer, not references, so it would make more sense doing the same for AddParent). Actually, the difference between a reference and a pointer is just in the declaration, because the compiled code is usually identical (in assembly, a reference and a pointer are the same thing)