Thanks for the advice.
Remo, it appears we are having some success with OSG 3.6.3. We still
need to build and test our main project, but it looks like osgviewer
is able to show both the terrain and the texture on a Mac.
Chris: we were not able to immediately see anything meaningful in the
OSG
We have run into an issue using textured terrain files under the MacOS that
have been created using the osgdem utilities of Virtual Planet Builder. The
terrains have been created on both Linux and the Mac directly and display
OK under Linux. On the Mac we are seeing the following error when
Paul,
Have you done a search in this mailing list/forum for nvidia 275? Follow
some of the threads you find, and see if any help you track down or fix
your problem.
Due to previous discussions on the topic, I have been careful to generally
avoid this specific driver.
I hope this helps...
D.J.
Hi Gianni,
In addition to the combined flag, I just noticed we are also applying the
material as close to the geometry as possible.
Let's say you have a top level group node that is your root. The children
of that group can either be geometry nodes or other groups. In our
project, when
, Nov 2, 2011 at 4:43 PM, D.J. Caldwell dlcaldwel...@gmail.comwrote:
Hi, again, Gianni...
I think our design approach is largely due to the fact that we only wanted
to apply our material to very specific parts of the scene graph, and
applying a material at a group node in our scene might cause
don't think it will actually help you in your case (but I could be
wrong; it happens often enough).
Still, the approach has some merit if you want that fine tuned control (and
if it worked the way you wanted it to work).
Sorry I couldn't help more...
D.J.
On Wed, Nov 2, 2011 at 1:13 PM, D.J
Hi Gianni,
On my project, we are using OSG 2.8.3, and we combine the
osg::StateAttribute::OVERRIDE flag with osg::StateAttribute::ON.
You might try:
[code]
root-getOrCreateStateSet()-setAttribute(material,
osg::StateAttribute::OVERRIDE|osg::StateAttribute::ON);
[/code]
That combination seems
Greetings to Jin and fellow OSG/Qt users.
Jin,
I am glad that you got your setup working. I am unsure of the specific
differences between g++ and Visual C++, but I would recommend that you be
careful using win32-g++ as your QMAKESPEC when using Visual Studio anything
as your build environment,
Hello Sukender,
In response to your backward compatibility suggestions, I believe clear
documentation is the key, and I believe you all are off to a good start in
that regard.
Inlining the deprecated functions with appropriate comment is a good start
for clear documentation in the source code.
Hi Gregoire, Sukender, and everyone,
While writing this email, I have come to the conclusion that I/we do not
really have anything (more) to be concerned about with tying user data and
description list to the meta-data system. If you are interested in some of
the concerns I already had, and that
Hi Sukender and fellow interested parties,
I've finally had a chance to review your meta-data doc (version 4) to see
what you all have been designing, and how we might be able to use it in our
project.
Overall, I must say the design looks good. I really appreciate the effort
you have put into
, the original
is probably preferred.
Perhaps I should have read that doc more than three times...
Regardless, I look forward to your comments and the final product.
D.J.
On Fri, Apr 29, 2011 at 11:01 PM, D.J. Caldwell dlcaldwel...@gmail.comwrote:
Hi Sukender and fellow interested parties,
I've finally
Hi Sukender,
I, too, have been following this thread with interest. I have not had the
time or resources to go over your documentation, yet, but I hope to do so
soon.
In my current project, we have adapted the osg::Node::DescriptionList to
store some basic run time data at the node level. My
Hi, Chris.
I have been using OSG 2.8.3 built as 64 bit shared libraries with VS2010 (no
SP1) on 64 bit Windows 7 for several weeks now, with no real problems.
Specifically with OSG, using CMake 2.8.3, I only had problems with the
INSTALL target; it appears the .lib, .dll, and .exe files weren't
:13 PM, D.J. Caldwell dlcaldwel...@gmail.comwrote:
Hi, Chris.
I have been using OSG 2.8.3 built as 64 bit shared libraries with VS2010
(no SP1) on 64 bit Windows 7 for several weeks now, with no real problems.
Specifically with OSG, using CMake 2.8.3, I only had problems with the
INSTALL
Hello, Werner.
If I read your createObject correctly, you appear to be returning a raw
pointer to an object that gets deleted within the function. Using ref_ptr
in the local scope, but returning a raw pointer, results in the deletion of
the object when you leave the function, since the only live
Hello, Christian.
If you overload the virtual function, QOSGWidget::paintEngine, to
return 0, you may see improvement. In the past, that is what has
worked for me, and the option has been discussed in this list. Do a
search on the archives for paintEngine and/or Qt paint for more
detail. Also,
Hi, Christian,
I am using OSG 2.8.3, and I haven't had a chance to work with the
newer code and examples. Your suggestion of reorganizing the classes
might help, but since I haven't looked at the code myself, that's as
much as I can say about that.
With more detail about your source code, maybe
back to 1.6 for now for different reasons but would like to upgrade.
Please do share hw you worked around the runtime problems.
Cheers,
Brad
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of D.J
Hi Brad.
We have only been using VPB 0.9.10 with OSG 2.8.3 for a little while,
but we found using GDAL 1.6 worked, but 1.7 did not. I'm not sure
what the exact problem was, but I think we had a runtime error (I
know, you're experiencing linker problems) having to do with mapping
the texture to
Hello, Zachary.
I use cow.osg for most of my testing. It may not be the most
intensive geometry, but it seems to work for testing simple behaviors.
Try searching the OSG archives for paintEngine. You should find a
fix that MIGHT help with what you're seeing. Under Microsoft Windows,
there
, if it works at all for Ubuntu).
Double check documentation for Qt events and OSG's interaction with
them. That's my best advice...
Sorry I couldn't be more help with this part...
D.J.
On Wed, May 26, 2010 at 4:35 PM, D.J. Caldwell dlcaldwel...@gmail.com wrote:
Hello, Zachary.
I use cow.osg for most
J-S,
If I follow the code and this thread correctly, I don't think this a
bug; I think it's a limitation of the current implementation.
For example...
If I have nodes masked by type (Craft, Planet, Debris, etc), and I
only want to pick nodes of certain types (Craft and Planet, but NOT
Debris),
] [VirtualPlanetBuilder][build] Which Versions of
GDAL and/or Squish Are Required?
On 4/2/2010 3:31 PM, D.J. Caldwell wrote:
So, my question is: did I miss where the required versions of GDAL and
Squish are specified? If so, where can I find that information?
I use GDAL 1.6, but I would think
...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of D.J.
Caldwell
Sent: 12 April 2010 16:05
To: OpenSceneGraph Users
Subject: Re: [osg-users] [VirtualPlanetBuilder][build] Which Versions of
GDAL and/or Squish Are Required?
Thanks to Chris and Martin for your
Maybe slightly off topic, but somewhat related: boost is currently
experimenting/working on a cmake build alternative for their system.
Perhaps this could help (confirm) your setup(s)?
Keep us all posted on the 64bit front...
Thanks...
D.J.
On Thu, Feb 25, 2010 at 4:19 AM, Morné Pistorius
Sorry; what I meant was, boost is experimenting using cmake to build
boost, as an alternative to their boost build system.
Hope this helps...
D.J.
On Thu, Feb 25, 2010 at 1:46 PM, D.J. Caldwell dlcaldwel...@gmail.com wrote:
Maybe slightly off topic, but somewhat related: boost is currently
David,
After looking into Paul's suggestion, I believe that (for static
terrain) if you add your terrain to your scaling node, and then use
Paul's suggestion on the scaling node, you may get what you're looking
for. The Optimizer is much simpler than my original suggestion,
although you may
Hello, David.
If your terrain is static, I would recommend an osg::NodeVisitor used
on your terrain in combination with osgUtil::TransformAttributeFunctor
used on the drawables of your terrain. As far as I know, this is a
custom solution, so you'll have to look into both of these classes to
see
Hi Fausto and Robert,
If the simple modification is due to some specific user event (button
press, file dialog, etc.), I might recommend refactoring the code to
add/remove nodes instead of drawables. It sounds like you have no
trouble initially getting the geometry into the scene; it is the
, D.J. Caldwell dlcaldwel...@gmail.com
wrote:
Hi Fausto and Robert,
If the simple modification is due to some specific user event (button
press, file dialog, etc.), I might recommend refactoring the code to
add/remove nodes instead of drawables. It sounds like you have no
trouble initially
Hi, Dominic.
I'm not sure this method is the best option for what you want, but I
don't have any ready alternatives myself, so I'll just answer your
question and move on.
I would recommend reading the following FAQ:
http://www.parashift.com/c++-faq-lite/const-correctness.html
In that context,
François,
I'm glad I could help.
Thanks for your reply; I was afraid that my explaination might not
have made much sense (which is why I posted the link with my reply).
We all have things to learn; we will just have to keep searching for
good things to know and share that knowledge when we can.
Hi, François.
A using directive can be used for things other than namespaces.
In this case, the using directive introduces all instances of
supports and accepts from the class Drawable scope (I think
they're all in the public scope of that class) into the public scope
of class ShapeDrawable;
Cedric, Martin, et al.
I'm glad the null-returning QPaintEngine function seems to work for you.
Unfortunately, I don't really have any other suggestions for testing
it to determine whether or not you should label the fix acceptable.
This is a question each project team must answer for
Greetings OpenSceneGraph/Qt users,
I, also, noticed bad behavior (blinking and such) with the QOSGWidget
example code. It has been a while since I last worked with it, but I
believe that after digging around in the documentation and deep in the
source code that I (partially) corrected the
Sorry, I should have said this fix instead of my fix; someone
else may have seen this, too, or I may have gotten the idea from
someone else (directly, indirectly, or otherwise).
Thanks,
D.J.
On Mon, Dec 14, 2009 at 1:14 PM, D.J. Caldwell dlcaldwel...@gmail.com wrote:
Greetings OpenSceneGraph
Hi, Maxim,
Qt can be built and used with a no_keywords flag so that Qt does not
redefine the names emit, signal, or slot. One uses Q_EMIT, Q_SIGNAL,
and Q_SLOT instead.
The no_keywords flag exists so that Qt doesn't cause interference with
3rd party signal/slot mechanisms, but I think it
Hi, everyone.
I'm sorry, no_keywords may be more than some people bargin for. What
I mentioned is true, but there are other side effects. Specifically,
Qt may redefine foreach and forever unless no_keywords is used (they
provide Q_FOREACH and Q_FOREVER as alternatives).
I'm not trying to
Strictly speaking, I am not sure these are OSG questions as much as they
are Qt questions, but since I am a developer an OSG/Qt app myself, I
will share what little I know.
I know that reparenting under some windowing systems can invalidate
window IDs, so that might be related to your BadWindow
.NET Framework Version 2.0 SP2
Microsoft Windows XP Professional Service Pack 3 (win32)
NVIDIA GeForce Go 7950 GTX (nv4_disp.dll version 6.14.10.9422)
Thanks in advance!
D.J. Caldwell
___
osg-users mailing list
osg-users@lists.openscenegraph.org
41 matches
Mail list logo
