FOUND IT!!! :D
works great with :
TextureChunkPtr tex_chunk = TextureChunk::create();
beginEditCP(tex_chunk);
tex_chunk->setInternalFormat(GL_RGBA_FLOAT32_ATI);
...
thanks again for reading :)
best regards,
Victor
On Sat, Jun 4, 2011 at 8:56 PM,
<opensg-users-requ...@lists.sourceforge.net>wrote:
> Send Opensg-users mailing list submissions to
> opensg-users@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/opensg-users
> or, via email, send a message with subject or body 'help' to
> opensg-users-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
> opensg-users-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Opensg-users digest..."
>
>
> Today's Topics:
>
> 1. Re: Problems processing line strips (Carsten Neumann)
> 2. Re: Problems processing line strips (Daniel Weber)
> 3. Re: Problems processing line strips (Daniel Weber)
> 4. Shader displacement map (Victor Haefner)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 03 Jun 2011 16:15:03 -0500
> From: Carsten Neumann <carsten_neum...@gmx.net>
> Subject: Re: [Opensg-users] Problems processing line strips
> To: opensg-users@lists.sourceforge.net
> Message-ID: <4de94ed7.6030...@gmx.net>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hello Daniel,
>
> I haven't had a chance to look at the code yet, thanks for providing the
> test file though!
>
> On 06/03/2011 10:43 AM, Daniel Weber wrote:
> > I'm using OpenSG2.0 to read line strips out of a .wrl file and process
> them afterwards. I've attached a sample file containing three line strips.
> In principle these line segments are connected, i.e., they represent a
> closed curve. I have some trouble with the whole process and I do not know
> if there are bugs or I'm missing something.
> >
> > 1) When reading the file, GL_LINES instead of GL_LINE_STRIPS are
> generated in the geometry core. A simple example shows the issue: At the end
> of the following code snipplet, the type of the geometry core is GL_LINES
> instead of GL_LINE_STRIP.
>
> hmm, that seems to be a case where the VRML loader/writer has taken a
> shortcut and just does not attempt to create LINE_STRIPS where it makes
> sense.
>
> > I fixed that in my application by traversing the generated scene graph
> and replacing all GL_LINES with GL_LINE_STRIP.
>
> that gives the expected visual result, but is a bit wasteful as you will
> have line segments of length 0 in the strip.
>
> > 2) In a second step I need to merge all geometry cores into one. As the
> geometry is spread over the whole the scenegraph and the GeometryMergeOp
> only works with direct children, I collected all geometry cores and put them
> "below" a group node ("newScene"). The merge operation works in principle,
> but it always results in two geometry cores: one with the merged geometry
> and another one. I assume that the "second" one is simply not deleted in the
> final step. Here is the code:
>
> that does indeed sound like a bug.
>
> > 3) In the third step, I call "createSharedIndex" in order to merge
> vertices that belong more than on line segment (these are the start- and
> end-vertices of the line strips.) With the attached file, only two of the
> three start-vertices are merged with the corresponding end-vertex. What may
> be the reason?)
> >
> > 4) Finally, I would like to make one linestrip out of the geometry. But
> the StipeGraphOp does not seem to work for linestrips (only tri- and
> quadstrips?)
>
> yes, the striper only handles triangle strips.
>
> In general the GraphOps are meant to perform optimizations that are
> applicable to all models so they may not necessarily give optimal
> results for specific cases like yours. That is not to say that the
> behaviour you are seeing indicates bugs that should be fixed, just that
> it may be hard to get the generic GraphOps to produce the exact result
> you are expecting.
> I would recommend considering to write your own GraphOp for the specific
> scene/optimization you require. Merging Geometry that is known to only
> contain line strips should not be very difficult and it's much easier to
> get the optimal representation you are looking for that way than by
> tweaking the generic code.
>
> Cheers,
> Carsten
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 04 Jun 2011 16:44:23 +0200
> From: "Daniel Weber" <megawe...@gmx.de>
> Subject: Re: [Opensg-users] Problems processing line strips
> To: opensg-users@lists.sourceforge.net,
> opensg-users@lists.sourceforge.net
> Message-ID: <20110604144423.27...@gmx.net>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Carsten,
>
> -------- Original-Nachricht --------
> > Datum: Fri, 03 Jun 2011 16:15:03 -0500
> > Von: Carsten Neumann <carsten_neum...@gmx.net>
> > An: opensg-users@lists.sourceforge.net
> > Betreff: Re: [Opensg-users] Problems processing line strips
>
> > Hello Daniel,
> >
> > I haven't had a chance to look at the code yet, thanks for providing the
> > test file though!
> >
> > On 06/03/2011 10:43 AM, Daniel Weber wrote:
> > > I'm using OpenSG2.0 to read line strips out of a .wrl file and process
> > them afterwards. I've attached a sample file containing three line
> strips.
> > In principle these line segments are connected, i.e., they represent a
> > closed curve. I have some trouble with the whole process and I do not
> know if
> > there are bugs or I'm missing something.
> > >
> > > 1) When reading the file, GL_LINES instead of GL_LINE_STRIPS are
> > generated in the geometry core. A simple example shows the issue: At the
> end of
> > the following code snipplet, the type of the geometry core is GL_LINES
> > instead of GL_LINE_STRIP.
> >
> > hmm, that seems to be a case where the VRML loader/writer has taken a
> > shortcut and just does not attempt to create LINE_STRIPS where it makes
> > sense.
>
> But writing and reading the geometry results in a different visualization.
> When rendering the first node (before writing to "test.wrl") you can see a
> straight line, while the one after the read results in a line stipple.
>
>
> >
> > > I fixed that in my application by traversing the generated scene graph
> > and replacing all GL_LINES with GL_LINE_STRIP.
> >
> > that gives the expected visual result, but is a bit wasteful as you will
> > have line segments of length 0 in the strip.
> >
> > > 2) In a second step I need to merge all geometry cores into one. As the
> > geometry is spread over the whole the scenegraph and the GeometryMergeOp
> > only works with direct children, I collected all geometry cores and put
> them
> > "below" a group node ("newScene"). The merge operation works in
> principle,
> > but it always results in two geometry cores: one with the merged geometry
> > and another one. I assume that the "second" one is simply not deleted in
> the
> > final step. Here is the code:
> >
> > that does indeed sound like a bug.
> >
> > > 3) In the third step, I call "createSharedIndex" in order to merge
> > vertices that belong more than on line segment (these are the start- and
> > end-vertices of the line strips.) With the attached file, only two of the
> three
> > start-vertices are merged with the corresponding end-vertex. What may be
> the
> > reason?)
> > >
> > > 4) Finally, I would like to make one linestrip out of the geometry. But
> > the StipeGraphOp does not seem to work for linestrips (only tri- and
> > quadstrips?)
> >
> > yes, the striper only handles triangle strips.
> >
> > In general the GraphOps are meant to perform optimizations that are
> > applicable to all models so they may not necessarily give optimal
> > results for specific cases like yours. That is not to say that the
> > behaviour you are seeing indicates bugs that should be fixed, just that
> > it may be hard to get the generic GraphOps to produce the exact result
> > you are expecting.
> > I would recommend considering to write your own GraphOp for the specific
> > scene/optimization you require. Merging Geometry that is known to only
> > contain line strips should not be very difficult and it's much easier to
> > get the optimal representation you are looking for that way than by
> > tweaking the generic code.
>
> Yes, I did that already, but not as a OpenSG GraphOp. If I have some time,
> I can transform the code into an OpenSG compatible one and make it available
> for you.
>
> Regards,
> Daniel
>
> >
> > Cheers,
> > Carsten
> >
> >
> ------------------------------------------------------------------------------
> > Simplify data backup and recovery for your virtual environment with
> > vRanger.
> > Installation's a snap, and flexible recovery options mean your data is
> > safe,
> > secure and there when you need it. Discover what all the cheering's
> about.
> > Get your free trial download today.
> > http://p.sf.net/sfu/quest-dev2dev2
> > _______________________________________________
> > Opensg-users mailing list
> > Opensg-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/opensg-users
>
> --
> NEU: FreePhone - kostenlos mobil telefonieren!
> Jetzt informieren: http://www.gmx.net/de/go/freephone
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 04 Jun 2011 16:44:23 +0200
> From: "Daniel Weber" <megawe...@gmx.de>
> Subject: Re: [Opensg-users] Problems processing line strips
> To: opensg-users@lists.sourceforge.net,
> opensg-users@lists.sourceforge.net
> Message-ID: <20110604144423.27...@gmx.net>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Carsten,
>
> -------- Original-Nachricht --------
> > Datum: Fri, 03 Jun 2011 16:15:03 -0500
> > Von: Carsten Neumann <carsten_neum...@gmx.net>
> > An: opensg-users@lists.sourceforge.net
> > Betreff: Re: [Opensg-users] Problems processing line strips
>
> > Hello Daniel,
> >
> > I haven't had a chance to look at the code yet, thanks for providing the
> > test file though!
> >
> > On 06/03/2011 10:43 AM, Daniel Weber wrote:
> > > I'm using OpenSG2.0 to read line strips out of a .wrl file and process
> > them afterwards. I've attached a sample file containing three line
> strips.
> > In principle these line segments are connected, i.e., they represent a
> > closed curve. I have some trouble with the whole process and I do not
> know if
> > there are bugs or I'm missing something.
> > >
> > > 1) When reading the file, GL_LINES instead of GL_LINE_STRIPS are
> > generated in the geometry core. A simple example shows the issue: At the
> end of
> > the following code snipplet, the type of the geometry core is GL_LINES
> > instead of GL_LINE_STRIP.
> >
> > hmm, that seems to be a case where the VRML loader/writer has taken a
> > shortcut and just does not attempt to create LINE_STRIPS where it makes
> > sense.
>
> But writing and reading the geometry results in a different visualization.
> When rendering the first node (before writing to "test.wrl") you can see a
> straight line, while the one after the read results in a line stipple.
>
>
> >
> > > I fixed that in my application by traversing the generated scene graph
> > and replacing all GL_LINES with GL_LINE_STRIP.
> >
> > that gives the expected visual result, but is a bit wasteful as you will
> > have line segments of length 0 in the strip.
> >
> > > 2) In a second step I need to merge all geometry cores into one. As the
> > geometry is spread over the whole the scenegraph and the GeometryMergeOp
> > only works with direct children, I collected all geometry cores and put
> them
> > "below" a group node ("newScene"). The merge operation works in
> principle,
> > but it always results in two geometry cores: one with the merged geometry
> > and another one. I assume that the "second" one is simply not deleted in
> the
> > final step. Here is the code:
> >
> > that does indeed sound like a bug.
> >
> > > 3) In the third step, I call "createSharedIndex" in order to merge
> > vertices that belong more than on line segment (these are the start- and
> > end-vertices of the line strips.) With the attached file, only two of the
> three
> > start-vertices are merged with the corresponding end-vertex. What may be
> the
> > reason?)
> > >
> > > 4) Finally, I would like to make one linestrip out of the geometry. But
> > the StipeGraphOp does not seem to work for linestrips (only tri- and
> > quadstrips?)
> >
> > yes, the striper only handles triangle strips.
> >
> > In general the GraphOps are meant to perform optimizations that are
> > applicable to all models so they may not necessarily give optimal
> > results for specific cases like yours. That is not to say that the
> > behaviour you are seeing indicates bugs that should be fixed, just that
> > it may be hard to get the generic GraphOps to produce the exact result
> > you are expecting.
> > I would recommend considering to write your own GraphOp for the specific
> > scene/optimization you require. Merging Geometry that is known to only
> > contain line strips should not be very difficult and it's much easier to
> > get the optimal representation you are looking for that way than by
> > tweaking the generic code.
>
> Yes, I did that already, but not as a OpenSG GraphOp. If I have some time,
> I can transform the code into an OpenSG compatible one and make it available
> for you.
>
> Regards,
> Daniel
>
> >
> > Cheers,
> > Carsten
> >
> >
> ------------------------------------------------------------------------------
> > Simplify data backup and recovery for your virtual environment with
> > vRanger.
> > Installation's a snap, and flexible recovery options mean your data is
> > safe,
> > secure and there when you need it. Discover what all the cheering's
> about.
> > Get your free trial download today.
> > http://p.sf.net/sfu/quest-dev2dev2
> > _______________________________________________
> > Opensg-users mailing list
> > Opensg-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/opensg-users
>
> --
> NEU: FreePhone - kostenlos mobil telefonieren!
> Jetzt informieren: http://www.gmx.net/de/go/freephone
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 4 Jun 2011 20:56:34 +0200
> From: Victor Haefner <victor.haef...@gmail.com>
> Subject: [Opensg-users] Shader displacement map
> To: opensg-users@lists.sourceforge.net
> Message-ID: <BANLkTimN=oppskej-paw2agzqdhfrt2...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi all,
>
>
> I am using 1.8
>
> I need a displacement mapping for a square lattice, with 128x128 512x512
> ...
> vertices for example
>
> I have a new map for every frame
>
> I looked at shaders today for the first time, I love them!! :D
>
> ..but I realy don't get how to pass the textures to the shader :(
>
>
> first the shader :
>
> string dcShader::disp_vp_program =
> "uniform sampler2D displacementMap;"
> "\n"
> "void main(void) {"
> " vec4 newPos;\n"
> " vec4 dv;\n"
> " float df;\n"
>
> " vec2 texture_coordinate;\n"
> " gl_TexCoord[0].xy = gl_MultiTexCoord0.xy;\n"
>
> " dv = texture2D(displacementMap, gl_TexCoord[0].xy);\n"//---here is the
> problem!
>
> //" dv = vec4(10.0 , 10.0, 10.0 ,0.0);\n"//---this works!
>
> " df = dv.x + dv.y + dv.z;\n"
>
> " newPos = vec4(gl_Normal * df, 0.0) + gl_Vertex;\n"
> " gl_Position = gl_ModelViewProjectionMatrix * newPos;"
> "}";
>
> string dcShader::disp_fp_program =
> "vec4 fvAmbient = vec4(0.5, 0.5, 1.0, 1.0);\n"
> "\n"
> "void main(void)"
> "{"
> " gl_FragColor = fvAmbient;"
> "}";
>
> SHLChunkPtr shl = SHLChunk::create();
>
> beginEditCP(shl);
> shl->setVertexProgram(disp_vp_program);
> shl->setFragmentProgram(disp_fp_program);
> endEditCP(shl);
>
> //my material
>
> UChar8* data = new UChar8[rN*cN*4];
>
> for(int i=0;i<rN*cN*4;i++) data[i] = 1;
>
> ImagePtr img = Image::create();
> beginEditCP(img);
> img->set( Image::OSG_RGBA_PF, cN, rN, 1, 1, 1, 0, data,
> Image::OSG_FLOAT32_IMAGEDATA);
> endEditCP(img);
>
> SimpleTexturedMaterialPtr Mat =
> SimpleTexturedMaterial::create();
> beginEditCP(Mat);
>
> Mat->setDiffuse(Color3f(0.8,0.8,0.6));
> Mat->setAmbient(Color3f(0.4, 0.4, 0.2));
>
> beginEditCP(Mat);
> Mat->addChunk(shl);
> endEditCP(Mat);
>
> Mat->setImage(img);
> Mat->setMinFilter(GL_NEAREST);
> Mat->setMagFilter(GL_NEAREST);
> Mat->setEnvMode(GL_NONE);
> endEditCP(Mat);
>
>
> the problem :
>
> no displacement when I use the texture data and the application becomes
> realy slow, but it works perfectly with any other values like the vertex
> position etc..
> my problem is also that I have no clue how to debug a shader.. is there any
> way for console output?
> and even if I could know the values from the texture in the shader.. if
> they
> are wrong I don't know what to do.. I have no clue how the texture is
> supposed to get to the shader :/
>
> thanks for reading!
>
> Best Regards,
>
> Victor
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
>
> ------------------------------
>
> _______________________________________________
> Opensg-users mailing list
> Opensg-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opensg-users
>
>
> End of Opensg-users Digest, Vol 61, Issue 2
> *******************************************
>
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
