GLSL compiler seams to be more strict in SVN version

29 views
Skip to first unread message

sherholz

unread,
Dec 16, 2011, 9:11:28 AM12/16/11
to G3D Users
Hi,

I was using G3D9 beta 2 for some time now and I wanted to update my
code to the current Svn version.
But I am having some problems to make it work as it was doing under
beta2.

In my GLSL code I am using some cg stuff (like half2 and pack_2half())
which was working fine under beta2
but when I am using the current SVN version I am getting a compiler
error.
I am also getting more compiler errors because I forgot to add
#version 130 at the beginning
but that obviously my fault ;)

I already try to compare the b2 sources with the current svn sources
but I couldn't
find the reason why the GLSL compiler works so different know?

Cheers

Sebastian

Morgan McGuire

unread,
Dec 16, 2011, 9:31:53 AM12/16/11
to g3d-...@googlegroups.com
The compiler is in your driver, so we have no control over it.

As far as I know, half2, etc. are now reserved words and illegal to use.  They are not currently supported as precision by any existing GLSL.  You can do:

#define half2 vec2

etc. to avoid changing your code, and can put a standard set of Cg defines in a header and #include it to avoid putting this in every file.

-m

Prof. Morgan McGuire
Computer Science Department
Williams College
http://cs.williams.edu/~morgan

sherholz

unread,
Dec 16, 2011, 11:46:54 AM12/16/11
to G3D Users
Hi Morgan,

that it could be a driver problem was also my first idea. But
the problem is, that I am not getting the error when I link my
program against G3D9 b2 (which I just compiled from source again
just to make sure ;)).

Do you have any other idea why the new G3D acts so differently??

Cheers

Sebastian


On Dec 16, 3:31 pm, Morgan McGuire <mor...@cs.williams.edu> wrote:
> The compiler is in your driver, so we have no control over it.
>
> As far as I know, half2, etc. are now reserved words and illegal to use.
>  They are not currently supported as precision by any existing GLSL.  You
> can do:
>
> #define half2 vec2
>
> etc. to avoid changing your code, and can put a standard set of Cg defines
> in a header and #include it to avoid putting this in every file.
>
> -m
>
> Prof. Morgan McGuire
> Computer Science Department

> Williams Collegehttp://cs.williams.edu/~morgan


>
> On Fri, Dec 16, 2011 at 9:11 AM, sherholz

> <sebastian.herh...@googlemail.com>wrote:

Morgan McGuire

unread,
Dec 16, 2011, 12:06:30 PM12/16/11
to g3d-...@googlegroups.com
It initializes openGL 3.x instead of 2.x, and that might be more strict.

-m

Prof. Morgan McGuire
Computer Science Department
Williams College
http://cs.williams.edu/~morgan


Corey Taylor

unread,
Dec 16, 2011, 10:20:32 PM12/16/11
to g3d-...@googlegroups.com
Is there a different GLSL version reported in the log.txt file generated for each build?  I'm wlling to bet they are different and therefore technically different compilers.
 
corey

sherholz

unread,
Dec 20, 2011, 8:55:44 AM12/20/11
to G3D Users
hi corey,

I also checked that. But both version (G3D9b2) and the current Svn
version are using GLSL 3.3.0
here is the output of the log files:

G3D9b2:
*
*
This driver will NOT support G3D 9.00:
GLSL version 3.30 yes (GLSL version on this driver
is 3.30)
GPU Supports OpenGL 3.3 or later (OpenGL version on this driver is
3.3)
GL_ARB_seamless_cube_map (yes)
GL_ARB_sample_shading NO - Required for G3D 9.0!


*
*
G3D {

Link version = 90002

Compile version = "G3D 9.00 beta 2"

G3D9DATA = "C:\\G3D9Svn\\data-files"

}

GPU {

Chipset = "GeForce GTX 295/PCI/SSE2"

Vendor = "NVIDIA Corporation"

Driver = "8.17.12.8562"

OpenGL version = "3.3.0"

Textures = 32

Texture coordinates = 8

Texture units = 4

GL_MAX_TEXTURE_SIZE = 8192

GL_MAX_CUBE_MAP_TEXTURE_SIZE = 8192

GL_MAX_COLOR_ATTACHMENTS = 8

}

G3D9Svn:
*
*
This driver will NOT support G3D 9.00:
GLSL version 3.30 yes (GLSL version on this driver
is 3.30)
GPU Supports OpenGL 3.3 or later (OpenGL version on this driver is
3.3)
GL_ARB_seamless_cube_map (yes)
GL_ARB_sample_shading NO - Required for G3D 9.0!


*
*
G3D {

Link version = 90003

Compile version = "G3D 9.00 beta 3"

G3D9DATA = "C:\\G3D9Svn\\data-files"

}

GPU {

Chipset = "GeForce GTX 295/PCI/SSE2"

Vendor = "NVIDIA Corporation"

Driver = "8.17.12.8562"

OpenGL version = "3.3.0"

Textures = 32

Texture coordinates = 8

Texture units = 4

GL_MAX_TEXTURE_SIZE = 8192

GL_MAX_CUBE_MAP_TEXTURE_SIZE = 8192

GL_MAX_COLOR_ATTACHMENTS = 8

}

I was able to activate the cg functions again by adding the

#pragma optionNV(strict off)

to the shaders. The compile still gives me errors when I forgot to add


#version 130 at the beginning

but that is my fault.

It would be still interesting to know what changed the behavior of the
compiler in the new version.

Another question I have is: where is the best place to report bugs?
here or at the sourceforge bug tracker.
For example in the Svn version the camera booksmarks are not working
anymore.
Everytime I create or select any camera from the list the system
crashes.
there seems to be a Nullpointer problem at:
Widget.cpp

void WidgetManager::fireEvent(const GEvent& event) {
if (GEventType(event.type).isGuiEvent()) {
GuiContainer* parent = event.gui.control->m_parent;
if (parent != NULL) {
if (parent->onChildControlEvent(event)) {
// The event was suppressed by the GUI hierarchy
return;
}
}
}
m_window->fireEvent(event);
}


event.gui.control is NULL.

so maybe the gui element wasn't setup correctly.

Cheers

Sebastian

Morgan McGuire

unread,
Dec 20, 2011, 10:27:58 AM12/20/11
to g3d-...@googlegroups.com
Are you sure that you have the latest SVN sources?  I fixed that NULL pointer bug (or one like it) shortly after the last beta release.

I'm working on the bookmark system right now and it may be a little bit unstable.

-m

Prof. Morgan McGuire
Computer Science Department
Williams College
http://cs.williams.edu/~morgan


sherholz

unread,
Dec 21, 2011, 3:46:07 AM12/21/11
to G3D Users
Hi Corey,

I am using the latest SVN sources.
I don't mind if the system is still a little bit unstable (hey it't is
still under development, right? *G*).

I think you guys really do a great job with G3D and I am happy if I
can help a little bit by finding some bugs during the process.

Cheers

Sebastian


On Dec 20, 4:27 pm, Morgan McGuire <mor...@cs.williams.edu> wrote:
> Are you sure that you have the latest SVN sources?  I fixed that NULL
> pointer bug (or one like it) shortly after the last beta release.
>
> I'm working on the bookmark system right now and it may be a little bit
> unstable.
>
> -m
>
> Prof. Morgan McGuire
> Computer Science Department
> Williams Collegehttp://cs.williams.edu/~morgan
>
> On Tue, Dec 20, 2011 at 8:55 AM, sherholz
> <sebastian.herh...@googlemail.com>wrote:

sherholz

unread,
Jan 4, 2012, 6:46:22 AM1/4/12
to G3D Users
Hi guys,

I hope you had some nice time over the holidays.
I had some time to play around with the problem of the camera
bookmarks.
I found out that changing the code in WidgetManager::fireEvent to:

void WidgetManager::fireEvent(const GEvent& event) {
if (GEventType(event.type).isGuiEvent()) {
if(event.gui.control!=NULL){
GuiContainer* parent = event.gui.control->m_parent;
if (parent != NULL) {
if (parent->onChildControlEvent(event)) {
// The event was suppressed by the GUI hierarchy
return;
}
}
}
}
m_window->fireEvent(event);
}

does work for me. I am not sure if this is the best solution because I
don't know if the control just shouldn't be NULL
but I couldn't find any place in the source code when creating the
bookmark list in CameraControlWindow.

Cheers and happy new year

Sebastian

On Dec 21 2011, 9:46 am, sherholz <sebastian.herh...@googlemail.com>
wrote:

Corey Taylor

unread,
Jan 7, 2012, 1:23:34 AM1/7/12
to g3d-...@googlegroups.com
Morgan,

Is there a parent for a top-level control?  Is that what he is encountering or what this already addressed?

corey

Morgan McGuire

unread,
Jan 7, 2012, 1:29:46 AM1/7/12
to g3d-...@googlegroups.com
I fixed a bug related to this in December and checking whether the reported issue still exists in SVN is on my TODO list (there were higher priority bugs to get to first).

The root pane of a GuiWindow has no parent.  I think the bug he saw/the one I fixed is that some events (correctly) do not have controls associated with them; I modified the handling of these in December.

-m

Prof. Morgan McGuire
Computer Science Department
Williams College
http://cs.williams.edu/~morgan


Morgan McGuire

unread,
Jan 14, 2012, 8:58:25 PM1/14/12
to g3d-...@googlegroups.com
I added an assertion to WidgetManager::fireEvent, but I believe it is now the case that all GUI events have non-NULL controls.  It is now the case that GUI_CLOSE returns false for isGuiEvent(), for example.  (should isGuiEvent be named "isGuiControlEvent"?)

-m

Prof. Morgan McGuire
Computer Science Department
Williams College
http://cs.williams.edu/~morgan


Reply all
Reply to author
Forward
0 new messages