Game Development Community

Torque3D OpenGL Status

by Luis Anton Rebollo · in Torque 3D Professional · 02/24/2013 (1:33 pm) · 175 replies

I am working with BeamNG in port Torque3D to OpenGL. When finished there will be a merge with GG repository.

I will be updating this thread at least once a week.
Repository: Github.com/BeamNG/Torque3D/tree/dev_linux_opengl

Status:

  • Is a research & learn branch, lots of unfinised and ugly code. It will check and clean all code before repo merge with GG
  • Basic Lighting & Advanced Lighting render correctly (more or less) all effects.
  • There may be errors or differences with other implementations of OpenGL. They will be corrected later.
  • No Oculus rift port to glsl.

How to compile:

* Use this manual.
* On Windows you need to check TORQUE_OPENGL option.

Reporting bugs:

If possible, Github is a great place to post issues to a forum.

Torque 3D Version:

This branch is based on Torque3D 3.5 development.

OpenGL performance:

I check the code in a new Gerforce 750ti and T3D works just as fast in Opengl/Directx9.
The problems of speed it was a few months ago were due to drivers. Sounds like a good OpenGL performance is linked to new cards/drivers. NVidia of Kepler architectures (Geforce 600-700) not sure on AMD.

I appreciate any donation to help the project. https://www.paypalobjects.com/en_US/i/btn/btn_donate_LG.gif.

img24.imageshack.us/img24/9537/ssx8.pngimg547.imageshack.us/img547/3684/opengl0.pngimg21.imageshack.us/img21/214/opengl1.pngimg27.imageshack.us/img27/1646/opengl2t.png
#121
03/10/2014 (1:44 am)
@ James, it is difficult to debug some shaders :(

The only thing I can think of ... Have you checked that you are using the correct cascaded map? Try setting ScatterSky.numSplits = 1 in the editor to see what happens. If not the problem, you may discard it.

Quote:Also has anyone noticed any problems with the shaders rendering green / orange artefacts on OSX (typically when rendering the glow & lighting specular)?
I think I've encountered this bug in Windows. I'll fix it today.
#122
03/10/2014 (11:39 am)
Quote:Also has anyone noticed any problems with the shaders rendering green / orange artefacts on OSX (typically when rendering the glow & lighting specular)?

@James, Try this code to see if it solves the problem

void GFXGLDevice::clear(U32 flags, ColorI color, F32 z, U32 stencil)
{
   // Make sure we have flushed our render target state.
   _updateRenderTargets();
   
   bool writeAllColors = true;
   bool zwrite = true;
   bool writeAllStencil = true;
   const GFXStateBlockDesc *desc = NULL;
   if (mCurrentGLStateBlock)
   {
      desc = &mCurrentGLStateBlock->getDesc();
      zwrite = desc->zWriteEnable;
      writeAllColors = desc->colorWriteRed && desc->colorWriteGreen && desc->colorWriteBlue && desc->colorWriteAlpha;
      writeAllStencil = desc->stencilWriteMask == 0xFFFFFFFF;
   }
   
   glColorMask(true, true, true, true);
   glDepthMask(true);
   glStencilMask(0xFFFFFFFF);
   

   ColorF c = color;
   glClearColor(c.red, c.green, c.blue, c.alpha);
   glClearDepth(z);
   glClearStencil(stencil);

   GLbitfield clearflags = 0;
   clearflags |= (flags & GFXClearTarget) ? GL_COLOR_BUFFER_BIT : 0;
   clearflags |= (flags & GFXClearZBuffer) ? GL_DEPTH_BUFFER_BIT : 0;
   clearflags |= (flags & GFXClearStencil) ? GL_STENCIL_BUFFER_BIT : 0;

   glClear(clearflags);

   if(!writeAllColors)
      glColorMask(desc->colorWriteRed, desc->colorWriteGreen, desc->colorWriteBlue, desc->colorWriteAlpha);
   
   if(!zwrite)
      glDepthMask(false);

   if(!writeAllStencil)
      glStencilMask(desc->stencilWriteMask);
}
#123
03/11/2014 (8:39 pm)
Not sure if this is in any way useful, but it wandered across my Github home feed: "Direct3D -> OpenGL translation layer".
#124
03/12/2014 (12:02 pm)
We were talking about that in IRC. I wish i had time to implement it into Torque.
#125
03/12/2014 (5:24 pm)
Wow! Nice library from Valve.

@Tim,
I had to take a double take on your name as I saw that code was from Valve. Is there any chance you are related to Gabe?
#126
03/13/2014 (8:29 am)
Heh no I am not. I wish i was, get uncle gabe to fund our game :p
#127
03/14/2014 (7:53 am)
@Anton doesn't seem to have fixed the problem here. Probably something weird happening in the shaders on my end. Will let you know if I figure it out.
#128
03/14/2014 (2:25 pm)
A new update on Github:github.com/BeamNG/Torque3D/tree/dev_linux_opengl
  • Increase FrameAllocator size to 32MB from 16.
  • HW instancing fix.
  • GLSL 150 WIP.
  • Fix: sample variable cause problems on some drivers.
  • Small changes for OpenGL 3.2 core profile context.
  • Fix: Write to depth buffer are activated after prepass.
  • Cache activate/deactivate vertex attribs.
  • Fix: Shadergen NormalsOutFeatGLSL::processVert, generate a mat...
  • Fix: Terrain textures not blend properly
  • Fix: Reflect Cubemaps render wrong.
  • Fix: Skybox not render.
  • Fix: GFXGLTextureTarget::resolveTo create and destroy FBO with...
  • Fix: Remove FFP from GFXGLCubemap
  • Fix: GFXGLTextureObject::getTextureData() return bad data.
  • Fix: GFXGLDevice::clear sometimes not clear correctly the rend...
  • Fix: GFXGLCubemap::bind are not cache.

An important thing about OpenGL perforamnce. I check the code in a new Gerforce 750ti and T3D works just as fast in Opengl/Directx9.

The problems of speed it was a few months ago were due to drivers. Sounds like a good OpenGL performance is linked to new cards / drivers

@James :(

@Daniel, thx for the link.... I try to learn something new :D
#129
03/14/2014 (4:19 pm)
I will have to try out the new changes in our game. I know I was getting a lot slower framerates on my nvidia card and terrible framerates on intel card.
#130
03/14/2014 (4:42 pm)
Testing on windows here with a NVidia GTX 560ti and GL performance is still way down on D3D9 using 335.23 driver.

Just a really small typo in gfxD3D9PCDeviceProfiler.cpp

#include <d3d.h>


needs to be d3d9.h
#131
03/14/2014 (6:00 pm)
I seem to be getting a problem with the render targets using the latest code. What seems to be happening is when its doing the glow pass its either selecting the wrong texture or its using the wrong mip level (since it looks a bit pixellated too). The end result is the glow is too extreme since its using the wrong image to blur with.

When using the old GFXGLTextureManager::innerCreateTexture code with the GL_GENERATE_MIPMAP_SGIS flag set on the texture, everything renders correctly.

Come to think of it should screen RTT targets actually have mipmaps anyway?
#132
03/15/2014 (1:31 am)
@Tim, thx for review changes.

@Timmy, when I referred to new cards, was NVidia of Kepler architectures (Geforce 600-700) not sure on AMD. Or so I hope hehehehe.

@James, added to mi ToDo. Thx.
#133
03/21/2014 (8:35 am)
Been having a little problem with the generic shader setup in PrimBuilder. It doesn't take into account the settings set in the current active state block, so for instance if you just wanted to render a texture without any color modulation you'd be a bit stuck.

I solved this by replacing the useGenericShaders block in PrimBuilder::end with the following...

// In GFXDevice...
   inline GFXStateBlock* getStateBlock() { return mCurrentStateBlock; }

   // In PrimBuilder::end...
   if ( useGenericShaders )
   {
	   GFXStateBlock *currentBlock = GFX->getStateBlock();
	   if (currentBlock && currentBlock->getDesc().samplersDefined)
	   {
		   if (currentBlock->getDesc().vertexColorEnable)
			   GFX->setupGenericShaders( GFXDevice::GSModColorTexture );
		   else
			   GFX->setupGenericShaders( GFXDevice::GSTexture );
	   }
	   else
		   GFX->setupGenericShaders( GFXDevice::GSColor );
   }

This also eliminates the need for the mNeedTexture variable.

Hope this is useful to anyone with a similar problem! :)
#134
03/26/2014 (4:37 am)
Sorry for delay.

Thx for all bugs reports/fixes :D

A new update on Github:github.com/BeamNG/Torque3D/tree/dev_linux_opengl
  • Fix: PrimBuilder can't render a texture without any color modu...
  • Fix: GLSL compiler errors on lightRayP.glsl
  • Fix: GFXGLTextureTarget::attachTexture does not accept GFXText...
  • Orphan vertex/primitive buffer when posible.
  • Review/clean.
  • Clean glsl. Rename VARYING to in/out.
  • Refactor vertex buffer and vertex format.
  • GL_ ARB_vertex_attrib_binding
  • Clear HW instancing.
  • Small fixes for BL.

New OpenGL branch: dev_opengl_temporal_no_use_2

Please do not use this branch will be overwritten and finally removed.
I have separated the OpenGL code, reviewing and reducing the necessary changes to facilitate works to T3D committe for a future T3D 4.0 pull request.

I would appreciate your help to test this branch, you can do it in Windows. It is especially important to check that Directx9 working properly.

I am now working on a SDL2 branch for window & input, and may next week start working on linux.

In a few weeks I'll do a merge with dev_linux_opengl for people using the old branch.
#135
03/26/2014 (4:42 am)
Luis - can your changes be made modular? I.e. have project generator flags to use DX or OGL? If there are changes to the GFX system that escape the OGL-specific code they should be merged separately to the OGL specific parts, IMO. I'll test out the branch in the next couple of days to make sure DX9 is still sitting pretty!
#136
03/26/2014 (5:03 am)
@Daniel

Good idea about move GFX changes to a separate pull request. I try to create 2 branches one for development(if posible) and one for T3D 4.0

For Opengl, we are already using TORQUE_OPENGL in c++, would only have to modify the project generator.

Make DX9 modular may be more complicated but I'll get them.

#137
03/26/2014 (7:56 am)
Regarding my state block change, it seems the new state block gets assigned to mNewStateBlock not mCurrentStateBlock, so it's better to return the former in getStateBlock.
#138
03/26/2014 (8:09 am)
@James, thx added to my ToDo.
#139
03/27/2014 (8:16 am)
Regarding my render target issue, it seems the problem was in fact something else related to the mipmaps. The compressed DDS files we were loading only had one mipmap level, so a call was needed to generate the mipmaps for those textures with insufficient numbers of mipmaps.

On the shader glitch front, after fixing a problem with sampler mapping in my codebase it seems to have fixed itself.
#140
03/28/2014 (8:22 pm)
Man, this is really coming along. I can finally use OpenGL for editing if I save frequently and it has only a few crashes.