On 3/22/2011 9:12 PM, Simon Kolciter wrote:
> Well, the problem is that the normal vertices are PER_VERTEX, not
> PER_PRIMITIVE.
> In Geometry shader, I only have access to the current primitive, not the
> whole mesh, right?
Correct.
> I need to
> 1. calculate the normal vector of each face (
Well, the problem is that the normal vertices are PER_VERTEX, not PER_PRIMITIVE.
In Geometry shader, I only have access to the current primitive, not the whole
mesh, right?
I need to
1. calculate the normal vector of each face (triangle) and add it to the normal
vectors of all 3 vertices
2. n
Hi again,
Thank you for your reply!
I've tried to set the path to what you have suggested me. In my case, I set it
to point at the hl2 root as you said.. well, apparently some models are
successfully loaded with all textures correctly applied onto them. However,
some still lack all the textur
Hi Tim,
I appreciate the comments. Up to this point I do not yet know what a shader does for a
living... except that I presumed it "shaded" surfaces somehow.
So... that will be my first step... I wouldn't have known that they were involved in
"cutting" (culling) unwanted sections of objects,
On 03/22/2011 04:44 PM, tim paige wrote:
And... I'm sure you or others might suggest the ultimate shading tutorial...
This one seems good. I haven't read the whole thing, but I've used
sections of it in the past...
http://www.lighthouse3d.com/opengl/glsl/
That, together with the osgshader
In an old version of osg I called to these functions:
setTargetFrameRate();
setMaximumNumOfObjectsToCompilePerFrame();
of the DatabasePager to control the maximum time that the simulation could
take to make the dynamic load.
The values I passed to this functions were smaller when I needed to
J-S, Thanks for the hints...
I appreciate the comments. Up to this point I do not yet know what a shader
does for a living... except that I presumed it "shaded" surfaces somehow.
So... that will be my first step... I wouldn't have known that they were
involved in "cutting" (culling) unwanted s
Hi Tom...
Thanks for taking a look and actually saying something... It is appreciated.
I had found the link you were showing me and learned a few more details that I
was able to use to move my little boat around and about quite effectively,
although some of those basic questions remain unanswer
On 3/22/2011 1:14 PM, Harash Sharma wrote:
> For one of the applications I working on, I need to attach some data to all
> the geometry
> nodes of the scenegraph. The data may be different for all the nodes. I need
> to use this
> data for some calculations during rendering. Is there a way to acc
Hi All,
For one of the applications I working on, I need to attach some data to all the
geometry nodes of the scenegraph. The data may be different for all the nodes.
I
need to use this data for some calculations during rendering. Is there a way to
access this data in the geometry / vertex / f
Hi Sukender,
You explanation of what you are doing in your app is way too light for
us to be able to guess what might be amiss. Are you running the
viewer? Is it just data preperation? I haven't got a clue.
Robert.
On Tue, Mar 22, 2011 at 5:42 PM, Sukender wrote:
> Hi all,
>
> Here's someth
Hi Tim,
I've never used NodeTrackerManipulator personally, nor have I used oceanExample
(or even PositionAttitudeTransform, I always just use MatrixTransform). So
obviously I won't be much help. However, I think maybe it would make sense for
you to make a small test application (small scene,
On 03/22/2011 12:31 PM, Chris 'Xenon' Hanson wrote:
You should be able to do what you're looking for on-GPU. There are some
cache and
read/write issues when you need to write to a data store and then immediately
read it back
and use it for drawing. Others can comment on that.
I haven't do
Hi there,
there are another two tiny patches I want to provide.
They fix two OpenGL errors (printed as OSG warnings to stdout/stderr) which
appeared on my machine when using a OpenGL ES 2 build.
1. One warning was written repeatedly to the terminal (while font rendering):
> Warning: detected Op
Hi all,
Here's something strange:
- I create PageLODs that will load files on disk when needed
- I create Groups of PagedLODs
- I write those groups to disk (OSGB/T format). They thus contain only few data
(just nodes and paths where data is).
- I create a PagedLOD which loads this newly file on
Hi Juan,
Only textures need to be bound during rendering, not texture buffers. Right
now, with your code, I am getting the following OpenGL calls during rendering:
Code:
// Primitive 1
glBindTexture(GL_TEXTURE_BUFFER, id);
glTextureBufferEXT(GL_TEXTURE_BUFFER, format, buffer_id);
glCallList(lis
Hi Tim,
When boat is placed in ocean at a specific waterline... when viewing from
above, that waterline is also in the boat.
Although my boat is in no immediate danger of sinking... what must I learn in
order to exclude the effect of the surface of the ocean from invading my space?
We do two
Hi Chris,
Am 22.03.2011 17:34, schrieb Chris 'Xenon' Hanson:
> On 3/22/2011 10:27 AM, Peter Hrenka wrote:
>> You could use a geometry shader to calculate
>> the normals on the GPU. The geometry shader
>> basically "sees" the whole primitive and can
>> can therefore perform the normal calculation
>
Hi all,
PagedLOD::traverse() reads:
if (_databasePath.empty())
//...
else
{
// prepend the databasePath to the child's filename.
nv.getDatabaseRequestHandler()->requestNodeFile(_databasePath+_perRangeDataList[numChildren]._filename,
On 3/22/2011 10:27 AM, Peter Hrenka wrote:
> You could use a geometry shader to calculate
> the normals on the GPU. The geometry shader
> basically "sees" the whole primitive and can
> can therefore perform the normal calculation
> of a deforming geometry.
I have been told by some hardware engin
On 3/22/2011 9:58 AM, Simon Kolciter wrote:
> 1. Push the list of vertices and primitive indices to the GPU.
> 2. Call GLSL function.
Fine so far.
> 3. Pull the resulting list of normals from the GPU.
Good lord, why? You're going to USE them on-GPU aren't you? Pulling them back
across the
b
On 3/22/2011 9:22 AM, Vincent Bourdier wrote:
> So first of all why not just give a patch to apply, provided with the sources
> or on the
> download wiki page ?
Oh, we could. But many organizations assign special importance to a named and
blessed
release, and won't let their developers run pat
Hi Simon,
Am 22.03.2011 16:58, schrieb Simon Kolciter:
> Hi,
>
> I have a model the geometry of which is being modified in real time and
> therefore, the PER_VERTEX normal vectors have to be updated as well.
>
> The modification of normals takes too much computing force, so I thought of
> push
Hi,
I have a model the geometry of which is being modified in real time and
therefore, the PER_VERTEX normal vectors have to be updated as well.
The modification of normals takes too much computing force, so I thought of
pushing the computation onto the GPU.
My question:
Is it possible to use
Hi,
When boat is placed in ocean at a specific waterline... when viewing from
above, that waterline is also in the boat.
Although my boat is in no immediate danger of sinking... what must I learn in
order to exclude the effect of the surface of the ocean from invading my space?
Thank you!
Chee
Hi,
I have found my object finally by turning off by NOT relying on
setAutoComputeHomePosition, and these other "set" creatures.
Code:
osgGA::NodeTrackerManipulator* nt = new osgGA::NodeTrackerManipulator();
nt->setNode(trackedNode);
nt->setTrackNode(trackedNode);
nt->setTrackerMode(osgGA::N
Hi,
It got rather lonely out here, but during my quiet time I have found that
perhaps one shouldn't use autocomputehomeposition. It seemed to take me to the
edge of my universe, and I finally found myself by racing forward forever until
my object appeared in the view.
In experimenting with pos
Hi,
So first of all why not just give a patch to apply, provided with the
sources or on the download wiki page ?
Regards,
Vincent.
Le 22/03/2011 16:14, Chris 'Xenon' Hanson a écrit :
On 3/22/2011 7:42 AM, Vincent Bourdier wrote:
So for this header issue, there is no planed change on 2.8
Hi, Issam
My 2 cents:
In general for efficient culling you should use quadtree-like more or less
regular graph structure (like 2d grid organized into tree). If there are lot of
low poly repeating entities you can try to use instancing to get speedup.
Depending on scene size and complexity you m
On 3/22/2011 7:42 AM, Vincent Bourdier wrote:
> So for this header issue, there is no planed change on 2.8.3 ?
> The only fix is to add the include by hand ?
> Thanks.
We've been discussing a 2.8.3.1 binary-compatible release to include JUST
this fix. But
there's been very little feedback on wh
Hi Robert,
I don't recall the specifics of LogicOp, but my guess is that the
OSG_GL_FIXED_FUNCTION_AVAILABLE was probably introduced to enable the
GLES1+GLES2 builds. You could try changing the defines uses to so
that only GLES builds disable LogicOp.
OK thanks, that makes sense. I'll try to sen
Hi,
As part of a Bugfix for osgearth I found a problem within osg's tiff plugin
(ReaderWriterTIFF.cpp):
http://forum.osgearth.org/sqlite3-caching-with-TIFFs-Bugfix-td6049357.html#a6192153
In essence:
When using the ReaderWriter on a std::stringstream the seeking operation should
not seek over
Hi Robert
well what i want to do is populating my pagedlod terrain for a flight-sim
application
i read in one of your posts that the problem is not how to render lot of
entities but how to generate them
i will grab the unfinished and abondoned dtTerrain library from delta3d that
generate vege
Hi,
So for this header issue, there is no planed change on 2.8.3 ?
The only fix is to add the include by hand ?
Thanks.
Regard,
Vincent.
Le 17/03/2011 19:32, D.J. Caldwell a écrit :
Sorry, everyone. I hit "Send" too fast before I could remember
something else import to my experience.
Ther
Hi Issam,
Rendering forest and urban areas is a huge topic, and how you'd go
about the task will depend a great deal on what content you have, what
hardware target you have and what your performance aims are. I'm not
about go write an 100 page essay on all the different ways you can
tackle it, s
Hi Juan,
I don't recall the specifics of LogicOp, but my guess is that the
OSG_GL_FIXED_FUNCTION_AVAILABLE was probably introduced to enable the
GLES1+GLES2 builds. You could try changing the defines uses to so
that only GLES builds disable LogicOp.
Robert.
On Tue, Mar 22, 2011 at 10:47 AM, Jua
Dear all,
I'm porting an application from OpenGL 2.x to OpenGL 4.x and I've found
out that LogicOp only works if OSG_GL_FIXED_FUNCTION_AVAILABLE is
defined. I've checked the OpenGL spec for versions 4.1 and 3.3 and
logical operations are part of it (no mention about deprecation).
Furthermore,
hi
i need some advices on how to achieve this tasks
which classes i must use to make this :
osg::lod, osg::pagedlod, osgsim::impostors, osgUtil::Simplifier ???
i need ideas or a schema on a scene graphe structure and thechniques to do this
i saw the osgforest sample don't use any lod or
Hi Ke?
Could you sign your post so we know how to address you, thanks.
In svn/trunk or the OSG-2.9.11 dev release you'll find a new version of the
osgUtil::SmoothingVisitor that supports a new aglorithm that uses a user
defined crease
angle to determine whether vertices that sit along edges that
39 matches
Mail list logo
