Hello Claudio / Julien,
This is still an unsolved problem for me, it normally occurs when I
integrate purchased models
in Remo3d (osg-based tool). Last time we discussed this I used osg
optimizer as a workaround
to rescale the normals but I would be really happy for a permanent fix.
I am not in
8 at 09:54, Robert Osfield
wrote:
> Hi Nick & Per,
>
> On Tue, 2 Oct 2018 at 06:12, Per Nordqvist wrote:
> > I and Nick are working to utilize as much of the GPUs as possible,
> either on single machine or cluster.
> > So hardware is not yet decided, but let's assum
Hello Chris, thanks for chipping in.
I and Nick are working to utilize as much of the GPUs as possible, either
on single machine or cluster.
So hardware is not yet decided, but let's assume ubuntu 16+, multiple
modern Nvidia gaming cards, but still single screen.
Cheers
Per
On Mon, 1 Oct 2018,
September as these
> releases, even point releases take a lot of me time.
>
> Cheers,
> Robert.
>
>
> On 28 May 2018 at 10:29, Per Nordqvist <nordqv...@gmail.com> wrote:
> > Just tested OpenSceneGraph-3.6.1-rc7 with my application, it builds fine
> but
> >
Just tested OpenSceneGraph-3.6.1-rc7 with my application, it builds fine
but some of my
animated FBX models are flipped upside down.
To display them correctly with osgviewer I have to use the metaloader:
osgviewer mymodel.fbx.(180,0,0).rot
Oddly, they load fine in osganimationviewer.
Not exactly
Hi there, thanks for your quick input.
@Robert; The use case is pretty common: the original model assumes mm, I
assume meters. Hence the extreme scaling.
Yes I noticed the transforms are flattened, which is probably a good thing
in my case but it shouldn't
change the rendering. (The model is
Hi all,
I came across something strange recently;
the attached model is a red triangle scaled down by a factor 1000.
The normals are squashed and I see some rendering problems in my app,
which uses osgcompositeviewer.
Confirmed with
osgcompositeviewer red.osgt - renders with white color
full time in Maya - hand painting
the roads and scenes.
When creating our graphics we use Maya, 3ds, Blender Remo3d (OSG based).
We also purchase models from turbosquid etc.
Feel free to contact me directly for non-OSG simulator discussions.
Cheers,
/Per Nordqvist
On 10 June 2015 at 15:10
Hi AP,
two ideas:
Play with sv-setCreaseAngle(something else than default PI)
or
yourNode-getOrCreateStateSet()-setAttributeAndModes(new
osg::FrontFace(osg::FrontFace::COUNTER_CLOCKWISE),
osg::StateAttribute::ON);
(CLOCKWISE or COUNTER_CLOCKWISE that is)
Hope this helps,
/Per
On 27 January
this.
Cheers,
Robert.
On 21 August 2014 10:25, Per Nordqvist nordqv...@gmail.com wrote:
Hi Robert, sorry for the late follow up, but I have now tested the cmake
trick from James,
it seems to do exactly what we want, i.e. replace the need for the
configure script.
I submit it here for further
. There are range of things that can cause
compilation to be slow, I haven't to head off line right now so will have
to leave you with that hint...
Robert.
On 2 September 2014 12:27, Per Nordqvist nordqv...@gmail.com wrote:
Hi all,
Another open-ended question I'm afraid
Hi all,
Another open-ended question I'm afraid, but maybe someone
has seen this before:
I sometimes see hiccups (rendering pauses) in my driving simulation,
I noticed it only happens with some vehicles, and only when they
appear in the frustum for the first time. I wonder how to minimize this
, the
IncrementalCompileOperation might help too. But you might need a newer
version of OSG.
Glenn Waldron / @glennwaldron
On Tue, Sep 2, 2014 at 7:27 AM, Per Nordqvist nordqv...@gmail.com wrote:
Hi all,
Another open-ended question I'm afraid, but maybe someone
has seen this before:
I sometimes see hiccups
path I'm curios to see an
example of how complex it gets.
/Per
On 2 September 2014 16:02, Robert Osfield robert.osfi...@gmail.com wrote:
Hi Per,
On 2 September 2014 14:18, Per Nordqvist nordqv...@gmail.com wrote:
Thanks guys for the answers! I guess it's OK to take a hit
Hi Robert, sorry for the late follow up, but I have now tested the cmake
trick from James,
it seems to do exactly what we want, i.e. replace the need for the
configure script.
I submit it here for further testing and review.
(osg trunk rev 14407, tested on Xubuntu 12.04 Cmake 2.8.7)
Maybe we
By default cmake doesn't select the Release build type so doesn't compile the
OSG with any
optimization enabled.
Robert: just curious, is there a reason not to use Release as default?
Simon: 3x slower?? Sounds like you should search for the problem somewhere else,
especially if you are on a
it to. For a flush you need to do use
std::endl. I believe this is appropriate std::ostream behaviour.
Robert.
On 9 July 2014 13:38, Per Nordqvist nordqv...@gmail.com wrote:
Hi Robert all,
When I run the program below I only see notice 2+3.
When I uncomment the 4th notice they all appear but in order
)
Thanks!
Per Nordqvist
--
#include osg/Notify
#include iostream
int main(int argc, char* argv[])
{
osg::notify(osg::NOTICE) 1 notify with \\n\n;
std::cout 2 cout with \\n\n;
std::cout 3 cout with endl std::endl;
// uncomment to display first notice
the paths in synk.
Thanks,
Per Nordqvist
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
your own private fork of the plugin...
Hope this helps,
J-S
On 06/09/2012 10:49 AM, Per Nordqvist wrote:
Hi J-S, thanks for responding. I assume you started from the Maya 2011
solution,
with Visual Studio 2008?
Im trying to compile now but I'm probably using the wrong version of OSG
2009/10/11.
Has there been any efforts on this plugin for Maya 2013?
Thanks,
/Per Nordqvist
p.s. the community page
http://www.openscenegraph.org/projects/osg/wiki/Community/Plugins
points to http://www.diosoft.com/soft/osgmaya/ but this page seems dead
There is a SDK archive here
http://usa.autodesk.com/adsk/servlet/pc/item?siteID=123112id=10775892
but the 2012.2 link seems to point to 2013.2.
Maybe ping them about it, this used to work before.
/Per
On 27 August 2012 14:07, Trajce Nikolov NICK
trajce.nikolov.nick@gmail.com wrote:
Hi
Not an OSG question actually; I believe newer gcc linker enforces
stricter rules about linking,
a workaround is to replace -lOpenThreads with -l/usr/lib/OpenThreads.so
or whereever you have installed your .so file.
/Per
On 1 February 2012 12:35, Alberto Luaces alua...@udc.es wrote:
Hobbes
I also struggled with this issue once and I believe osgspotlight suffers
from exactly the same quadrant defect if you look closely.
Would be really nice if somebody submitted a fix.
/Per
On 29 September 2011 01:59, Brad Colbert bcolb...@rscusa.com wrote:
Glenn,
** **
Bingo! That was
regards,
/Per Nordqvist
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Hi JP,
I had similar problem on 2.8.x, your code doesn't compile for me but
have your tried
wrapping the cursor stuff with
viewer.stopThreading();
..
viewer.startThreading();
/Per
On 26 May 2011 15:40, J.P. Delport jpdelp...@csir.co.za wrote:
Hi all,
the attached little app crashes if I
Hi guys, thanks for the quick replies. My code is ported from SGI Performer
and for some
reason the predraw switching technique used to work in there.
I've tested nodemasks now and they work fine, but I suppose I could
use switches in each
of the slave cameras as well if I want the flexibility to
pushing the limits of osgViewer, do I need to switch
to compositeviewer to achive this
or is there some other way? (I am using Fedora, OSG 2.8)
Thanks in advance,
Per Nordqvist
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http
Hi Vincent,
Just a guess:
You may want to doublecheck that actionBetweenFrames is not switching
the node which contains the update callback. That could cause all kinds
of shaking.
Regards,
/Per
2008/7/9 Vincent Bourdier [EMAIL PROTECTED]:
Hi all,
I have a similar problem than
29 matches
Mail list logo
