Maybe have a look at this:
http://orihalcon.jp/projdesigner/
cheers
jp
Murray Curtis wrote:
I have driving simulators with three projected screens 4.5 metres wide
arranged in half a hexagon that are viewed from slightly off center. The
car is centered but the driver is off to the left or
On Wed, Feb 27, 2008 at 10:06 PM, Night Hawk
[EMAIL PROTECTED] wrote:
Surprising indeed. I was about to override the Array classes to use native
c-style arrays. But now it seems OSG can convert vectors to C-style arrays
fast enough :)
The OSG wouldn't do it if it wasn't efficient, its
On Wed, Feb 27, 2008 at 11:59 PM, nicolas peña [EMAIL PROTECTED] wrote:
A little correction (to my self); I have done more tests and the image is
not set exactly to the size window,
(as I previously said) but changes its value in a similar manner.
I suspect the automatic window resize
Hi Paul,
On Thu, Feb 28, 2008 at 12:39 AM, Paul Martz [EMAIL PROTECTED] wrote:
First, the app requires a model file name on the command line, but appears
to ignore it in this case (-1 always loads and displays fountain.osg).
Probably just an oversight; I imagine the intent was to use
On Thu, Feb 28, 2008 at 1:05 AM, Vican, Justin E. [EMAIL PROTECTED] wrote:
Hi Justin,
1.) Are postDrawCallbacks supposed to be called before the POST_RENDER
camera sub graphs are rendered?
A camera post draw callback should be called after its whole subgraph
is rendered.
2.)Is there
On Thu, Feb 28, 2008 at 1:24 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I built the data base as 16 tiles of 4kx4k each tile
running osgdem -l 6 , would running -l 8 help performance?
It won't make any real difference. Things should scale comfortable to
level 18 and beyond. Level 6 and
Hi,
Thank you very much, it works great.
To be precise, I've added the Geode with ParticleSystem to the root node,
and the ParticleSystemUpdater and the Emitter to the target node, which
permit to work in relative coords and to render the particles well.
Thanks,
Vincent
2008/2/28, J.P.
Many thanks for the fix He, it works a treat, best appreciated when
exaggerating the field of view. The fix is now merged and submitted
to SVN.
On Wed, Feb 27, 2008 at 2:30 PM, hesicong2006 [EMAIL PROTECTED] wrote:
Hi, robert:
Call me He is ok, He Sicong is my Chinese name :-) I attached my
Hi Everyone interested in this topic.
Solution was very simple. All I had to do was to change my ShadowMap camera
RefernceFrame to ABSOLUTE_RF_INHERIT_VIEWPOINT.
Thanks to for solving this problem before Robert ;-)
Btw. osgShadow::ShadowMap still sets ABSOLUTE_RF maybe we could change it ?
I
I've run into a problem using Quaternion rotation with osg::Matrixd that I
can't seem to figure out. Consider the following test example and resulting
output:
#define DEG2RAD(d) d*(2*M_PI/360.0)
#define RAD2DEG(r) r*360.0/2*M_PI
void testQuaternionRotation()
{
osg::Matrixd osgTrans;
Hi Mike!
I have resolved the problem of the visualization of the skirt, using
osgTerrain::Locator, osgTerrain::NoDataValue, and drawing with
osgTerrain::GeometryTechnique instead of drawing the HeightFieldLayer
with ShapeDrawable.
I am using Locator however I don't want my terrain to be
On Thu, Feb 28, 2008 at 2:14 PM, aurora restivo [EMAIL PROTECTED] wrote:
I am using Locator however I don't want my terrain to be drawn using the
locator-setCoordinateSystemType(osgTerrain::Locator::GEOCENTRIC)
I have tried to apply GEOGRAPHIC but it doesn't visualize anything.
I
I built the data base as 16 tiles of 4kx4k each tile running
osgdem -l 6 , would running -l 8 help performance?
In the first case, you have 6 levels of detail, in the second you have 8.
The presence of additional levels of detail will not affect the rendering
performance of the existing 6
Hi,
seems like the matrix.getrotate is broken again. 'osgunittests quat'
also reports lots of problems.
I'm comparing with old working versions, will let you know.
jp
[EMAIL PROTECTED] wrote:
I've run into a problem using Quaternion rotation with osg::Matrixd that I
can't seem to figure
Hi Paul,
Second, and more worrisome, the TrackballManipulator appears to be
ignored with the -1 argument. In other words:
1) Run osgcompositeviewer -1 cow.osg on a dual-screen Windows system.
2) Two fullscreen windows open, displaying fountain.osg.
3) Use left or right mouse motion in
Hi Robert,
There is a bug and bug fix relating to picking and CompositeViewer,
but I haven't yet had the time to investigate if this bug or review
the bug fix. There is chance its related to the above.
It is. :-)
J-S
--
__
Jean-Sebastien
On Thu, Feb 28, 2008 at 3:02 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
I haven't gotten any news about it being integrated into SVN yet, and
your report seems to confirm it hasn't... Any reason for that Robert? Is
there anything I need to do to get it integrated?
I haven't reviewed
Hi,
When using osgText::Text with SCREEN_COORDS I have experienced similar
problems as disussed in the referenced thread and I'm wondering if this
suggested patch has been implemented? If not, why?
I'm currently using OSG 2.0.
Regards
Jonas
On Mon, Dec 10, 2007 at 1:18 PM, Thibault Genessay
I did not use osgPPU but it seems like it's ideal for the job! I don't want
to think about how much time I've could have saved by using it..
There is however the question of how to apply the result. Ambient occlusion
should of course only apply to ambient part of the light model.
Something like
Hi,
J.P. Delport wrote:
Hi,
seems like the matrix.getrotate is broken again. 'osgunittests quat'
also reports lots of problems.
sorry, I've spoken too soon. Matrix.getrotate is fine. The unittests
report false positives (q = -q is OK), will fix this.
For your problem angles,
Hi Robert,
I haven't reviewed it yet. I did mostly clear my backlog on my
return, but since then have had to get on with other tasks, and the
backlog has grown back again... W.r.t merging submissions it tends to
be first submitted gets reviewed first unless the submission itself
requires
Hi,
seems like the matrix.getrotate is broken again. 'osgunittests quat'
also reports lots of problems.
sorry, I've spoken too soon. Matrix.getrotate is fine. The unittests
report false positives (q = -q is OK), will fix this.
I promise to still fix the unittests...
For your problem
This is a really cool example. :) Is there any way an option could be
added so that the 3rd person view is rendered on top of the regular view
(eliminating the need for 2 windows?) This would be informative when
someone wants to create a rear-view mirror display or something.
Or, does
On Thu, Feb 28, 2008 at 4:14 PM, Jeremy Moles [EMAIL PROTECTED] wrote:
This is a really cool example. :) Is there any way an option could be
added so that the 3rd person view is rendered on top of the regular view
(eliminating the need for 2 windows?) This would be informative when
someone
On Thu, 2008-02-28 at 09:11 +, Robert Osfield wrote:
On Wed, Feb 27, 2008 at 10:06 PM, Night Hawk
[EMAIL PROTECTED] wrote:
Surprising indeed. I was about to override the Array classes to use native
c-style arrays. But now it seems OSG can convert vectors to C-style arrays
fast enough
Hi,
I've skimmed the OSG website, but I could not find any quick guides to
migrating from version 1.2 to 2.2. Is there such a place on the website? In
particular, I'm running into problems with various OSG and Producer functions
that are no longer supported such as
Thanks J.P. for all the help, this problem was starting to give me a headach.
For future refrence, this is how to get the correct angle of rotation about the
z-axis:
quat.getRotate(angle,axis);
double zAxisRotation = angle*axis.z();
-Original Message-
From: [EMAIL
Oops, I meant Producer::Camera::setProjectionRectangle. There is no
osg::Camera class.
On Thu Feb 28 12:32 , Brian [EMAIL PROTECTED] sent:
Hi,
I've skimmed the OSG website, but I could not find any quick guides to
migrating from version 1.2 to 2.2. Is there such a place on the website?
Hi Brian,
On Thu, Feb 28, 2008 at 5:43 PM, Brian [EMAIL PROTECTED] wrote:
Oops, I meant Producer::Camera::setProjectionRectangle. There is no
osg::Camera class.
The OSG uses OpenGL naming conventions, so its just plain Viewport (as
in glViewport) rather than ProjectionRectangle. So what
On Thu, Feb 28, 2008 at 5:32 PM, Brian [EMAIL PROTECTED] wrote:
Hi,
I've skimmed the OSG website, but I could not find any quick guides to
migrating from version 1.2 to 2.2. Is there such a place on the website?
It's not too extensive, but a start at least:
Hi Justin -- Are you clearing the depth buffer before rendering the HUD?
camera-setClearMask(GL_DEPTH_BUFFER_BIT);
-Paul
Hi Robert,
Thanks for getting back to me. I still seem to be having an
issue with this. I've attached 3 simple images illustrating
the issue. The text overly
I'm having a problem trying to calculate the UP vector of a node as it
makes a 360 roll.
I'm setting the camera viewpoint like this:
//Update View
osg::Vec3 eye( cameraX, cameraY, cameraZ);
osg::Vec3 center(nodeX,nodeY,nodeZ);
osg::Vec3 up(nodeX,nodeY,nodeZ);
That's fine, I totally understand, I was just wondering if
there was something wrong but if it's just for lack of time I
totally understand.
(note that I'm not totally sure I did the right thing in the
fix, I just did what worked for me - I don't know the related
code that well so I
Hi Paul,
Yes. I based it almost verbatim off of the osghud example. If you look
at the top ~20 lines of createHUD in osghud.cpp, that is exactly what I
am doing.
Thanks,
Justin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
Martz
Sent: Thursday,
Problem found:
ReaderWriterOSG.cpp
107 line -
std::ifstream fin(fileName.c_str());
if (fin) //FALSE
{
return readNode(fin, local_opt.get());
}
return 0L;
// The open method on pre-MSVC8 ifstream implementations doesn't accept
Hi Robert,
Something is always better than nothing.
Thanks for the tip on setViewport. I'll most likely have other questions in
the near future.
Brian
On Thu Feb 28 13:24 , 'Robert Osfield' [EMAIL PROTECTED] sent:
On Thu, Feb 28, 2008 at 5:32 PM, Brian [EMAIL PROTECTED] wrote:
Hi,
Brian wrote on Thursday, February 28, 2008 1:37 PM:
Hi Robert,
Something is always better than nothing.
Thanks for the tip on setViewport. I'll most likely have other
questions in the near future.
And, of course, it's a wiki, so feel free to add to that something :)
Hello,
The following 2 posts are copied from the COIN mailing list Peder is a
Systems In Motion person.
John F. Richardson
= FROM COIN MAILING LIST ===
John Pye wrote:
Hi all
I've been reading the Inventor Mentor book and there is talk about
Hi Justin,
Look at void osgUtil::RenderStage::draw(osg::RenderInfo
renderInfo,RenderLeaf* previous) method.(Line 825 in currnt SVN
src/osgUtil/RenderStage.cpp). Its all there.
1: Prerender cameras add Prerender stages. Prerender stages are drawn first.
Line 833:
Hi again,
I should problably add one note here: One may say that Camera has getView
method. This method returns NULL for graph nested cameras. I pressume its
valid only for main views and slaves.
Cheers,
Wojtek
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf
Hello OSG users:
I am wondering what OSG can provide in solving the following problem:
Given a scene with on the order of 100s of simple geometry elements
(perhaps osg::Box types) and given an (x,y,z) position in that scene,
I'd like
1) A list of all polygonal planes that are *visible* from the
Hi Wojtek,
Yeah, I tried the osg::Camera::getView method with a nested callback
implementation, but was similarly disappointed. For now I think
correctly rendering at runtime is more important than accurate screen
grabs, so I'm going to go with a POST_RENDER HUD camera and write a bug
against my
I'd use OSG for this, although not the rendering portions.
You'll need to learn a whole lot about the scenegraph structure, how to
traverse it, accumulate tranformations, how to access geometric elements
(tris, quads,..), how to access normals, vertexs, colors, front vs back
facing,
All
I got it working!!!
In case anyone is interested, this is what I did.
I took a local point on the -Z axis of the entity.
localX = 0, localY=0, localZ=-1;
Converted it to World Coordinates (wX, wY, wZ), subtracted the center of
the entity in world coordinates.
Wx -= entityXWorld;
Wy -=
Hi folks,
I am unable to create complete darkness in osg. I'm setting the only
light source to not emit anything, but the objects in my scene are still
visible, although very faintly. Is there something wrong with the code,
or is it just osg/opengl?
osg::Light* light = new osg::Light();
Hi
I have a large area TerraPage visual database loaded in OSG. When my 3D
building models and light points (flt or ive) are planted close to the
origin, everything works well. But when they are planted at somewhere
far away, everything starts shaking and flickering, even at distances of
less
46 matches
Mail list logo