RE: G3D 8 Beta 2 Suggestions

[corey taylor]

(Please don't hijack a thread to start a discussion).

On Thu, Dec 3, 2009 at 6:18 PM, zybx <zyb...@gmail.com> wrote:

I have several suggestions:

1. 1D textures/NPOT 3D textures/Texture Array should be supported.

 

There really is no need for 1D textures.  Using a N x 1 texture is perfectly normal and allows the use of 2D samplers.

 

We don't use 3D textures nor volume texture files amongst the development team.  There was one user who needed support and added it as a customization.  If you have a real need for it, we can discuss supporting it better and required file formats.

 

 

2. Provide a way to save float-point textures/images to files such as
dds.

We have had the goal of adding better HDR support for a while but never had the task time to implement file formats that supported it amongst other things.  Morgan is currently looking into adding file formats that support more than 8-bits per channel.  I don't think we will add DDS writing though.

 

 

3. G3D programs often crashes in release mode (8.00b1, WinXP, VC9). I
think it is a memory bug because if I insert or remove some trival
code, it can run without crash. Sometimes the linking process stuck at
'embeding manifest...'. Debug mode has no such problem.

 

Can you provide a callstack for the crash?  We had a very hard to debug random crash in optimized executables a couple releases ago.  However, that was supposedly resolved by fixing our Visual Studio project settings.  Do only your programs crash or do G3D tools/demos crash as well?

 

What project is building when it hangs?  It may be an issue with program optimization.

 

corey

[Loki]

If you don't mind I also answer this. I took demos/models example and
just add such code into onGraphics() method in App.cpp file:
//--------------------
rd->beginOpenGL();
glBegin ( GL_QUADS );
glNormal3f ( 0.0f, 0.0f, 1.0f );
glVertex3f ( 1.0f, 1.0f, 2.0f );
glVertex3f ( 2.0f, 1.0f, 2.0f );
glVertex3f ( 2.0f, 2.0f, 2.0f );
glVertex3f ( 1.0f, 2.0f, 2.0f );

glNormal3f ( 0.0f, 0.0f, -1.0f );
glVertex3f ( 2.0f, 1.0f, 1.0f );
glVertex3f ( 1.0f, 1.0f, 1.0f );
glVertex3f ( 1.0f, 2.0f, 1.0f );
glVertex3f ( 2.0f, 2.0f, 1.0f );

glNormal3f ( -1.0f, 0.0f, 0.0f );
glVertex3f ( 1.0f, 1.0f, 1.0f );
glVertex3f ( 1.0f, 1.0f, 2.0f );
glVertex3f ( 1.0f, 2.0f, 2.0f );
glVertex3f ( 1.0f, 2.0f, 1.0f );

glNormal3f ( 1.0f, 0.0f, 0.0f );
glVertex3f ( 2.0f, 1.0f, 2.0f );
glVertex3f ( 2.0f, 1.0f, 1.0f );
glVertex3f ( 2.0f, 2.0f, 1.0f );
glVertex3f ( 2.0f, 2.0f, 2.0f );

glNormal3f ( 0.0f, 1.0f, 0.0f );
glVertex3f ( 1.0f, 2.0f, 2.0f );
glVertex3f ( 2.0f, 2.0f, 2.0f );
glVertex3f ( 2.0f, 2.0f, 1.0f );
glVertex3f ( 1.0f, 2.0f, 1.0f );

glNormal3f ( 0.0f, -1.0f, 0.0f );
glVertex3f ( 2.0f, 1.0f, 2.0f );
glVertex3f ( 1.0f, 1.0f, 2.0f );
glVertex3f ( 1.0f, 1.0f, 1.0f );
glVertex3f ( 2.0f, 1.0f, 1.0f );
glEnd ();

rd->endOpenGL();
//--------------------

and got a trouble mentioned above stuck over linking (Embedding
manifest...). But if I delete every glNormal3f(...) it linked well. I
really don't understand why it happens.

[corey taylor]

Interesting.  I've never encountered that particular problem before.  The best I could do is do some searching.  So far, there are no answers other than a reboot typically removed the temporary files that are stalling.

 

I have a feeling this is a Visual Studio issue for some version (I've seen reports of it for 2005) in combination with your setup.

 

I will keep looking for any official information, but you might have to post to the MSDN forums.

 

corey

[Loki]

I also supposed that this is a Visual Studio issue 'cause I recently
got this trouble after reinstall VS. I think under FreeBSD, Linux and
other POSIX problem doesn't exist.

On 4 дек, 07:56, corey taylor <corey.tay...@gmail.com> wrote:
> Interesting.  I've never encountered that particular problem before.  The
> best I could do is do some searching.  So far, there are no answers other
> than a reboot typically removed the temporary files that are stalling.
>
> I have a feeling this is a Visual Studio issue for some version (I've seen
> reports of it for 2005) in combination with your setup.
>
> I will keep looking for any official information, but you might have to post
> to the MSDN forums.
>
> corey
>

[corey taylor]

The manifest is a Windows concept so it doesn't apply to Linux.

 

corey

--

You received this message because you are subscribed to the Google Groups "G3D Users" group.
To post to this group, send email to g3d-...@googlegroups.com.
To unsubscribe from this group, send email to g3d-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/g3d-users?hl=en.

[Loki]

I know :) I meant linking against the library

[corey taylor]

Have you seen the crash running executables in release?  The issue we had a while ago would only occur when running outside of Visual Studio.

 

corey

On Thu, Dec 3, 2009 at 10:11 PM, Loki <lok...@gmail.com> wrote:

I know :) I meant linking against the library

[Loki]

No, running executables work perfectly. Problem appears only over
linking.

[zybx]

On 12月3日, 下午4时47分, corey taylor <corey.tay...@gmail.com> wrote:
> (Please don't hijack a thread to start a discussion).
>
> On Thu, Dec 3, 2009 at 6:18 PM, zybx <zyb...@gmail.com> wrote:
> > I have several suggestions:
>
> > 1. 1D textures/NPOT 3D textures/Texture Array should be supported.
>
> There really is no need for 1D textures. Using a N x 1 texture is perfectly
> normal and allows the use of 2D samplers.
>
> We don't use 3D textures nor volume texture files amongst the development
> team. There was one user who needed support and added it as a
> customization. If you have a real need for it, we can discuss supporting it
> better and required file formats.

I'm not saying to load 3D textures from certain file format. The only
problem is that the assertions are too restrict in G3D, which requires
that the size of 3D textures be power of two. Now I just moified some
assert commands in Texture.cpp such that NPOT 3D texture can be
created without error message.

> > 2. Provide a way to save float-point textures/images to files such as
> > dds.
>
> We have had the goal of adding better HDR support for a while but never had
> the task time to implement file formats that supported it amongst other
> things. Morgan is currently looking into adding file formats that support
> more than 8-bits per channel. I don't think we will add DDS writing though.

I agree. It is better to have a file format that support more than
8bits per channel. Especially float-point formats because sometimes
people want to save some computational results for further use.

> > 3. G3D programs often crashes in release mode (8.00b1, WinXP, VC9). I
> > think it is a memory bug because if I insert or remove some trival
> > code, it can run without crash. Sometimes the linking process stuck at
> > 'embeding manifest...'. Debug mode has no such problem.
>
> Can you provide a callstack for the crash? We had a very hard to debug
> random crash in optimized executables a couple releases ago. However, that
> was supposedly resolved by fixing our Visual Studio project settings. Do
> only your programs crash or do G3D tools/demos crash as well?
>
> What project is building when it hangs? It may be an issue with program
> optimization.

I always start with the starter project and insert some code in it.
There will be a change that the release build will crash at startup,
or even stuck during link process. To avoid this, I often comment/or
uncomment this line:

debugPane->addButton("Exit", this, &App::endProgram);

> corey

[Morgan McGuire]

I'm not saying to load 3D textures from certain file format. The only
problem is that the assertions are too restrict in G3D, which requires
that the size of 3D textures be power of two. Now I just moified some
assert commands in Texture.cpp such that NPOT 3D texture can be
created without error message.

Be careful: if you just comment out the assert, you are not loading an NPOT texture.  You are resizing your texture to be a power of two, and potentially losing a lot of data in the process.  The assert is there to warn you about it.

A lot more than the assert has to be changed: grep for all locations where DIM_3D appears; all of those locations need to be updated.  If I make the modification, will you test it  to make sure it works?
 

I always start with the starter project and insert some code in it.

There will be a change that the release build will crash at startup,
or even stuck during link process. To avoid this, I often comment/or
uncomment this line:

debugPane->addButton("Exit", this, &App::endProgram);

Are you still building within the original G3D.sln, or did you remake your own solution and project file?  Can you make it crash within G3D.sln?

-m

[zybx]

On 12月4日, 上午7时05分, Morgan McGuire <morga...@gmail.com> wrote:
> > I'm not saying to load 3D textures from certain file format. The only
> > problem is that the assertions are too restrict in G3D, which requires
> > that the size of 3D textures be power of two. Now I just moified some
> > assert commands in Texture.cpp such that NPOT 3D texture can be
> > created without error message.
>
> Be careful: if you just comment out the assert, you are not loading an NPOT
> texture. You are resizing your texture to be a power of two, and
> potentially losing a lot of data in the process. The assert is there to
> warn you about it.
>
> A lot more than the assert has to be changed: grep for all locations where
> DIM_3D appears; all of those locations need to be updated. If I make the
> modification, will you test it to make sure it works?

I didn't comment any assert, just modified the logic expressions in
the assert. There were several asserts modified.
But I think it is better to check the GL extensions before making
assertions rather than throwing an error directly.
The NPOT 3D texture works on my cards (Geforce GTX280), but it may not
be supported on other cards.

I would like to test it if you make the modification. Just send me an
email: ybzhang at ucdavis dot edu.

> > I always start with the starter project and insert some code in it.
> > There will be a change that the release build will crash at startup,
> > or even stuck during link process. To avoid this, I often comment/or
> > uncomment this line:
>
> > debugPane->addButton("Exit", this, &App::endProgram);
>
> Are you still building within the original G3D.sln, or did you remake your
> own solution and project file? Can you make it crash within G3D.sln?

I always make a new Win32 console project and solution and add app.h &
app.cpp into it.
I used to do this since G3D6. Do you mean that I have to use G3D.sln?

> -m

[zybx]

I just made a real-time fluid simulator and volume ray-caster based on
G3D, here is a video:
http://vis.cs.ucdavis.edu/~zhang/Fire01.mp4

On 12月4日, 上午7时05分, Morgan McGuire <morga...@gmail.com> wrote:

[Morgan McGuire]

>
> I always make a new Win32 console project and solution and add app.h &
> app.cpp into it.
> I used to do this since G3D6. Do you mean that I have to use G3D.sln?
>
>> -m

No, I just need a test case to find the problem, since it doesn't
happen to me. See if the projects within G3D.sln always work right.
If they do, then the problem must be in the way your new project files
are created. If they don't, then the problem is likely your VC
install.

-m

[zybx]

Ok, next time when I encountered this problem, I'll save a copy of it.
I cannot reproduce it right now because it happens randomly, usually
in the middle of a project.

[corey taylor]

I still feel like it's not project settings but an issue with Visual Studio on your system.  Have you searched the MSDN forums?

 

corey

2009/12/4 zybx <zyb...@gmail.com>

[zybx]

I had this problems on many different machines before. But all of them
have XP & VC9 (express/professional) installed.
It is likely a VC-related problem. The same code can be run on
Leopard.

> > g3d-users+...@googlegroups.com<g3d-users%2Bunsubscribe@googlegroups-.com>
> > .

> > For more options, visit this group at

> >http://groups.google.com/group/g3d-users?hl=en.- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[andyc]

Hi,

On Dec 4, 12:47 am, corey taylor <corey.tay...@gmail.com> wrote:
> (Please don't hijack a thread to start a discussion).
>
> On Thu, Dec 3, 2009 at 6:18 PM, zybx <zyb...@gmail.com> wrote:
> > I have several suggestions:
>
> > 1. 1D textures/NPOT 3D textures/Texture Array should be supported.
>
> There really is no need for 1D textures.  Using a N x 1 texture is perfectly
> normal and allows the use of 2D samplers.
>
> We don't use 3D textures nor volume texture files amongst the development
> team.  There was one user who needed support and added it as a
> customization.  If you have a real need for it, we can discuss supporting it
> better and required file formats.

Any comment on Texture Array? This is a very mainstrean feature
compared to 3d texture. A key usage is sending one batch with a k-
length texture array instead of k batches with regular textures. Other
examples here:
http://developer.download.nvidia.com/SDK/10.5/opengl/samples.html

Best,
Andrew

[Morgan McGuire]

Texture Array will definitely appear in G3D 9.x. I haven't looked at it for G3D 8.0 because we're so close to release.  If you have a detailed idea of how to merge it with the current API I'd be happy to consider that for 8.0, however.

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

--

You received this message because you are subscribed to the Google Groups "G3D Users" group.
To post to this group, send email to g3d-...@googlegroups.com.

To unsubscribe from this group, send email to g3d-users+...@googlegroups.com.

[andyc]

I'm going to look at this before Christmas but I don't have the
details now. I'll probaby hack in something throwaway for my needs.
That might at least give me some ideas that I can report back.

Nice to hear that this is on the agenda.

Best,
A

On Dec 9, 9:32 pm, Morgan McGuire <morga...@gmail.com> wrote:
> Texture Array will definitely appear in G3D 9.x. I haven't looked at it for
> G3D 8.0 because we're so close to release.  If you have a detailed idea of
> how to merge it with the current API I'd be happy to consider that for 8.0,
> however.
>
> -m
>
> Prof. Morgan McGuire
> Computer Science Department

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

> > g3d-users+...@googlegroups.com<g3d-users%2Bunsu...@googlegroups.com>
> > .

[Morgan McGuire]

Great.

If you look at the roadmap in the Wiki, we're trying to get a solid 8.0 out as the last GL 1.3+ release, and Corey and I are in parallel designing G3D 9.0 which will be GL 3.2+.  The RenderDevice, Shader, and Texture APIs are going to change radically, but everything else will pretty much stay the same.

-m

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

To unsubscribe from this group, send email to g3d-users+...@googlegroups.com.

[zybx]

I just realized my problem because I forgot to disable the 'Randomized
Base Address' option for linking.
But I still don't know why it should be turned off. Is it related to
the implementation of G3D?

On 12月4日, 下午6时41分, corey taylor <corey.tay...@gmail.com> wrote:

> > g3d-users+...@googlegroups.com<g3d-users%2Bunsubscribe@googlegroups-.com>
> > .

> > For more options, visit this group at

[Morgan McGuire]

I have no idea why this problem occurs.  It showed up when G3D passed a certain size.  I don't know if it is something in G3D or because all large programs have this issue under VC9.  We researched it for quite a while and found nothing, and no way of forcing the right linker flag from a pragma.

I'm hoping this will magically go away on VC10.  If anybody figures out why G3D programs need the no-random base address, let me know!

-m

2009/12/11 zybx <zyb...@gmail.com>

To unsubscribe from this group, send email to g3d-users+...@googlegroups.com.

[andyc]

Hi,

On Dec 10, 3:28 am, Morgan McGuire <morga...@gmail.com> wrote:
> Great.
>
> If you look at the roadmap in the Wiki, we're trying to get a solid 8.0 out
> as the last GL 1.3+ release, and Corey and I are in parallel designing G3D
> 9.0 which will be GL 3.2+.  The RenderDevice, Shader, and Texture APIs are
> going to change radically, but everything else will pretty much stay the
> same.

Are you thinking about bindless graphics, and separate compilation
(see slides 59 + here: http://www.slideshare.net/Mark_Kilgard/opengl-32-and-more)
at all, or do you have to stay conservative?

A.


>
> -m

[Morgan McGuire]

You can see the currently proposed APIs on the Wiki and in SVN (not CVS).

G3D has always isolated the user from binding to optimize state changes, so the bindless optimizations will allow the library to further increase performance.  Whether 9.0 uses it in the implementation depends on how widely the extension is supported and how big of a performance difference it makes.  In the long run, 9.x will probably use it at some point.

I'm not convinced that the separate shader compilation makes a difference.  OpenGL has always allowed you to mix-and-match shaders, although the link step was potentially slow in the past.  I've never seen a need for it myself, although without the default fixed-function vertex shader it could become a lot more important.  I'm currently leaning towards letting Shader re-use objects through an internal cache, but still presenting a single class that represents the entire linked shader.

Your feedback is welcome on all API decisions and proposals!

-m