Paul Martz wrote:
> I have done this before, and the results are interesting but not high
> quality due to differences in line/polygon rasterization. Still a good trick
> nonetheless.
>-Paul
Yeah, I've seen line rasterization on different graphics cards produce
different results, and sometime
Gordon Tomlinson wrote:
> Another old school Performer way, would be to double draw your node once in
> normal mode and then a second time in wire frame mode
An extension to this, which I've read about but never implemented is, after
rendering your object, set ztest to equal, switch to wireframe,
Happy New Year(in China , It is New Year.)
Gung hey fat choi!
-JD
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
Jean-Sébastien Guay wrote:
> The eye point is as expected, but instead I get center = (0,-39,0).
Presumably because getViewMatrixAsLookAt() doesn't do any magic, it just takes
the Y axis (in this case) of the matrix as the view vector. This vector will be
normalised (otherwise the camera would
Gianluca Natale wrote:
> Hi all,
>
> I'm new to OSG.
>
> I cannot find a way to change the primary color of OpenGL in order to draw
> the same
>
> object twice in two different places with two different colors.
Just to throw in a third alternative, you could create a simple shader that
took a c
Paul Martz wrote:
> * We could spend time writing short whitepapers on various OSG topics,
I'd be very much in favour of this form of documentation.
It allows users to pick and choose which papers to read, without having to buy
lots of doxygen output or stuff they already know.
Domain experts cou
Robert Osfield wrote:
> On Dec 11, 2007 6:31 AM, J.P. Delport <[EMAIL PROTECTED]> wrote:
>> could we get support for multiple render targets (MRT) integrated into
>> 2.4? I know some people are using hacky patches for this. Some patches
>> have been submitted, but they have to be reworked.
>>
>> I
Pettersson Håkan wrote:
>> Hello
>>
>> How do I calculate the yaw angle that my cameraManipulator is
>> pointg at (-PI to +PI) ???
>>
>> /Hakan
Hi Håkan,
Relative to what? If you want it relative to the +Z axis, then use
atan2(zdir.x, zdir.z), being careful to put in a special case where the cam
Do you want to fade to black, change scene, then fade up? Or do you want to
fade from one to another?
The first option is easiest, just draw a full-screen quad over the top of your
scene, changing the alpha from 0 to 1. Then change scenes and reverse the alpha
fade.
If you want to blend between sce
It largely depends on whether you're running a 64-bit or 32-bit OS. Naturally,
you'll need a 64-bit processor regardless!
I suspect that the thunking needed to run a 32-bit application in a 64-bit OS
will produce some overhead, but from my personal experience where I have a dual
boot Win32/Linux64,
Ralph Kern wrote:
> Hi,
>
> I now managed to get true float values out of the render buffer by
> specifying
>>> image = new osg::Image;
>>> image->allocateImage(width, height, 1, GL_RGB, GL_FLOAT);
>>> image->setInternalTextureFormat(GL_RGB32F_ARB);
>>> viewer->getCamera()->attach(
> Hi!
> I'd like to know whether "hidden line removed" (silhouette edges)
> rendering can be achieved with OccluderGeometry class ?
> In addition, i have found Shi Yazheng's article
> (http://www.cs.umu.se/education/examina/Rapporter/ShiYazheng.pdf)
> implementing SEDGeode, which seems a good s
andrej spilak wrote:
> I'd like to render a wireframe of an object with it's outer edges only.
> Basically only outline of an object. Are there any osg solutions?
If you want to render _just_ the outline, then the method I suggested will
still work, but you've just got to switch off rendering to
andrej spilak wrote:
> Hi!
> I've exported an object from SolidWorks and stored it in .osg format.
> Now I'm trying to get rendered the edges of an object (without triangles
> as are seen in wireframe in the osgviewer - only the edges wireframe).
> What would be best possible solution(s) to achi
Alberto Luaces wrote:
> I didn't know about this, thanks for the clarification. Is the performance
> loss still noticeable after the primitive is compiled in a display list?
I only found out by reading the excellent OSGQSG (Quick Start Guide), but makes
sense now I think about it.
I'm not sure o
Alberto Luaces wrote:
> Hi,
>
> I think you can specify a normal per polygon using Geometry::setNormalBinding
> and the parameter BIND_PER_PRIMITIVE.
>
This is true, but OSG will fall back to using glBegin()/glEnd() to render the
primitives, rather than using vertex arrays or display lists. Not
Cervantes Pintor Pedro wrote:
> Hi,
>
>
> I'm constructing a geometric object by hand. The way I'm doing it, is vertex
> by
> vertex and then polygon by polygon.
>
Hi Cervantes,
normals are really just a property of vertices, not faces. The way to get flat
faces with the fixed-function pipel
[EMAIL PROTECTED] wrote:
> thanks, I'll try that.
>
> more problems I'm facing is setting the image internal data type, I've seen
> in the examples setting the internal type to 3 or 4. what does it mean? how
> do I set it to float or int?
I use the following code for rendering to a floating-point
[EMAIL PROTECTED] wrote:
> second, I want to render single or several (4 - 8) values which represnt some
> calculation. So I use render to texture. The texture is 1D and to render to
> it I use orthographic projection, and the viewport fits to the texture
> dimension. The geometry I render is p
Igor Naigovzin wrote:
> Hello to all!
> I have a simple question.
> I want to render a two cameras (two different render surfaces) by exactly
> the same scene.
Hi Igor,
if I understand you correctly, you're doing the same sort of thing I am. I have
a few cameras rendering to the same texture.
This
J.P. Delport wrote:
> Hi,
>
> OK, here goes.
Thanks JP, that worked a treat!
> We need some mechanism to store/assign more than one drawbuffer inside
> "camera" and possibly a flag to indicate we want MRT. RenderStage can
> then inherit/query these values to properly call glDrawBuffer(s).
Yeah,
h instructions if you want it?
>
> regards
> jp
>
>
> John Donovan wrote:
>> Hi,
>> is there anything else I need to do to render to two textures with the same
>> fragment shader? I have the following code:
>> cam->setRenderTargetImpleme
Hi,
is there anything else I need to do to render to two textures with the same
fragment shader? I have the following code:
cam->setRenderTargetImplementation(Camera::FRAME_BUFFER_OBJECT);
cam->attach(Camera::COLOR_BUFFER0, _texture.get());
cam->attach(Camera::COLOR_BUFFER1, _textur
John Donovan wrote:
> I have a bunch of slave cameras set up under a osgViewer:Viewer, all looking
> at
> the same scene, and a GLSL program I want to run for each camera. But I want
> to
> pass in a per-camera uniform variable into my shader. Any idea how I should go
> a
I have a bunch of slave cameras set up under a osgViewer:Viewer, all looking at
the same scene, and a GLSL program I want to run for each camera. But I want to
pass in a per-camera uniform variable into my shader. Any idea how I should go
about this?
-J
__
John Donovan wrote:
> ...results won't necessarily be rendered anywhere.
On screen, that is.
-J
__
This email has been scanned by the MessageLabs Email Security System.
For more information please vi
Robert Osfield wrote:
> BTW, is there a reason why you aren't just using a single context and
> a FBO RTT Camera?
>
Not as such. But what I'm playing with is some GPGPU stuff where the results
won't necessarily be rendered anywhere. I'm really only using the textured quad
to check the results,
Robert Osfield wrote:
> If you wish to reuse texture objects generated by one context then you
> need to share the various contexts with each other. You can set this
> via the GraphicsContext::Traits::sharedContext variable.
Ah! OK, that makes sense. But I am having problems with it...
I have t
Is it possible to have a viewer with a RTT camera render with one
GraphicsContext, then to use that texture with another viewer and a different
GraphicsContext? It works ok if all the cameras use the same GC.
What I'm aiming for is to render to texture in a completely offscreen buffer,
then use tha
Hi Robert,
thanks for the quick reply. I've been playing around and it seems happy with
using the same texture to render into. I've since used just a osgViewer::Viewer
rather than the CompositeViewer, and it seems fairly happy.
-J
_
f (im) {
im->setFileName("c:\\temp\\test.png");
osgDB::writeImageFile(*im, im->getFileName());
}
Is there a step that I'm missing?
-John Donovan
__
This email has been scanned by the MessageLabs Email Sec
31 matches
Mail list logo