Jump to content

  • Log In with Google      Sign In   
  • Create Account


Laval B

Member Since 30 Jul 2010
Offline Last Active Today, 03:34 AM
-----

Topics I've Started

Qt and OpenGL

28 November 2013 - 05:04 AM

Hello everyone.

 

I have started porting our map editor from a MFC sdi application to a Qt application and i'm having issues with OpenGL. By the way i'm quite new to Qt. I'm nusing Qt 5.1.1 with Visual Studio 2012 toolchain and Qt Creator 2.8.1.

 

I have a QApplication with a main window derived from QMainWindow. The main window contains a few docking windows on the right, left and bottom docking area. For the main widget of the main window i subclassed QGLWidget for rendering. For some reason this widget is all black.

 

The QGLWidget subclass overrides only the initializeGL, resizeGL and painGL methods. The code for these methods is minimal :

/////////////////////////////////////////////////////////////////////////////////////////
/// One time initialization.
void SceneView::initializeGL()
{
    glEnable(GL_DEPTH_TEST);
    glClearColor(0.25f, 0.25f, 0.25f, 1.0f);
}

/////////////////////////////////////////////////////////////////////////////////////////
/// Called when the widget is resized.
void SceneView::resizeGL(int w, int h)
{
    // Setup viewport, projection etc.
    glViewport(0, 0, (GLint)w, (GLint)h);
}

/////////////////////////////////////////////////////////////////////////////////////////
/// Called when the widget is redrawn.
void SceneView::paintGL()
{
    glClear(GL_COLOR_BUFFER_BIT);
}

Whatever the clear color i chose, the widget is always black.

 

I have tried creating the widget with and without parent, creating the widget alone (only window in the application) and it didn't change anything. I have tried to call swapBuffers (which, according to the documentation i shouln't do) and it didn't work.

 

Also, i have notices that, when resizing either one of the docking widget, there is some flickering (only when the widgets are docked). This doesn't appen if i replace the central widget by a QTextEdit for example.

 

Anyone have any idea what the problem could be ? Some of the examples used basically the same method and they work.


Behavior of assignment with user data in Lua

17 October 2013 - 09:08 AM

Hello everyone.

 

I have created and exposed a C++ class to Lua as a user data. Meta function __gc has been written and it works fine. I can make multiple instances (using the new function) of that object in a script and call their methods and they work. However, the behavior of the assignment is not what i need it to be. It looks like variables in scripts are references to objects in the virtual machine. Therefore, if i write a statement like 

 

x = y

 

in a script where x and y are both user data of the same type, x becomes a reference to the same object as y. Is there a way to override this behavior ? I know it is possible to override comparisons by defining __eq meta function (ans __le, etc).

 

Is it also possible to prevent assignment where it doesn't make sense ?

 


lightuser data in Lua

15 October 2013 - 06:39 AM

Hello everyone.

 

An application we are working on needs some parts to be scripted. The scripts will only act as callbacks to controle some  part of the execution of some transactions. To do so, it must expose a few objects from the host application. The lifetime of these objects is well controled by the host and they will outlive the execution of the script. The logical choice seems to be the use of lightuser data.

 

We have exposed these objects using functions and lightuser data and it does work. However, lightuser data don't have their individual metatable. Instead, they all share the same so they all share the same metamethods. It would be great though if we could associate specific methods to each object exposed (like it can be done with full user data) so it would be possible to use object oriented programming notations on those objects from the script.

 

At the moment, we have to use a notation like this :


function f(user, logger)

   setName(user, "name")
   setGroup(user, "group")

   output(logger, "User is set.")

end

instead of 

function f(user, logger)

   user:setName("name")
   user:setGroup("group")

   logger:output("User is set.")

end

Is there a way to do this with lightuser data ?


Uniform blocks and Uniform buffer objects

04 July 2013 - 10:45 AM

Hello everyone.

 

 

I'm thinking about how i would implement a parameter system using OpenGL 3.2+ (core profile) and GLSL. I'm talking about uniform (not including samplers) and not vertex attributes. I'm leaning toward using UBOs and uniform blocks in shaders. Here are a few of points i'm not sure about.

 

  1. I'm planning to use only one big UBO which will contain all the parameters for all uniform blocks in all programs, specific parameters being updated using an appropriate call to glBufferSubData. So, all uniform blocks a program uses would be associated to the same uniform binding point, let's say 0, using glUniformBlockBinding and glBindBufferRange. Another interesting thing about using only one UBO is that i can bind this UBO at load time and keep it bound during rendering (no need to bind an UBO every time i need to update a parameter). Is it that correct and is there any problem with this method ?
  2. Since association happens only at initialization time, the uniform block index returned by glGetUniformBlockIndex doesn't need to be kept into a variable assuming this association doesn't change, correct ?

GLSL vertex attributes

16 June 2013 - 05:12 PM

Hello everyone.

 

My question is about vertex attributes. I'm targeting OpenGL 3.2 and above core profile with the corresponding version of GLSL. Is it ok to assign vertex attribute location using glBindAttribLocation before linking the program or is it preferable to just query them after linking. If i assign locations, some may not be contiguous e.g. position might be 0, normal 1 and texture coordiante 5, is that a problem ?


PARTNERS