Hi Jorge,
I know little about the issues of Android platform, so read with
interest in the various developments that yourself and others are
working on, it does mean I can't yet contribute too pro-actively
though. I'll will try and chip in where I can.
On Mon, Jan 17, 2011 at 10:37 PM, Jorge
Hi Ulrich,
I need the information on vertix level, not bounding volumn level. How does the
Render Engine know which vertices to draw. Is it all done in GPU using the Z
Buffer (overwriting what is nearer)?
I found the OcclusionQuery example that uses OcclusionQueryNode, but I can't
quite make
Hi Oliver,
On 18/01/11 20:23 , Oliver Neumann wrote:
I need the information on vertix level, not bounding volumn level. How does
the Render
Engine know which vertices to draw. Is it all done in GPU using the Z Buffer
(overwriting what is nearer)?
OSG does not check each vertex for
Hi,
Not sure if this or its been superseded, you might want to take a look at
OSGTDS.
http://andesengineering.com/Projects/TDS/
This is for deforming terrain for the placement of objects.
I have never used it, but it might be worth a shot?
Cheers
Martin.
-Original Message-
From:
Hi Alessandro,
I posted a fix a while back that may solve the issue you're referring to. If
it works for you then maybe with more prodding Cedric might accept it ;)
Here it is again, attached
On 17 January 2011 15:43, Alessandro Terenzi a.tere...@gmail.com wrote:
Hi,
no one else is
Hello everyone,
I'm new here so hi all and thanks in advance to everyone willing to take a look
on my issue. :)
I'm currently working on object selection in my scene, so I made something up
based on the picking example from osgpick.cpp .
Code:
if (myview-computeIntersections(x, y,
Hi,
When I compile your code I get the following errors:
Code:
error C2065: 'GL_TEXTURE_BUFFER_EXT' : undeclared identifier
error C2039: 'Extensions' : is not a member of 'osg::BufferObject'
error C2039: 'getExtensions' : is not a member of 'osg::BufferObject'
[...]
I don't see any
Hi,
I'm working with Jorge trying to get a native osg on Android.
The main problem that we found was the migration of OpenThreads, it's
not really complicated but there are some missing api in pthreads
(pthread_cancel as mentioned before) and some changes (sleep returns
void :O). We made the
Hi,
OK, I temporarily replaced Extensions with GLEW, things moved forward, but I'm
stuck with the following compilation error now:
Code:
} else if (_image.valid() _image-data()) {
/* Temporary copy */
osg::ref_ptrosg::Image image = _image;
/* Creating the texture
Hi Linda,
Its large and advanced topic. Various techniques work in different way. I
simply do not have the time to explain it. Besides, I follow the rule to not
respond in much more words than question asked (hint). If you are interested
in Shadow Mapping I may recomend starting from
Hi Robert,
Another day, another autobuild failure :-)
I'm kidding you of course.
http://cdash.openscenegraph.org/viewBuildError.php?buildid=3185
.\..\..\src\osgDB\DatabasePager.cpp(895) : error C2664: 'void
osgUtil::IncrementalCompileOperation::add(osg::Group *,osg::Node *)' :
cannot
Hi JS,
Caught this one already, fix checked in this morning ;-)
Robert.
On Tue, Jan 18, 2011 at 1:57 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Hi Robert,
Another day, another autobuild failure :-)
I'm kidding you of course.
I suggest looking at StandardShadowMap, MinimalShadowMap and the various
LiSPSM variations; based on my experience with osg 2.8.3 they offer the
most robust implementation of shadows. There is also a debugging mode
that you can enable that renders the depth map which is extremely
useful. As
So far I've tried osg 2.8.3 and 2.9.10 and have not been able to get any
results using the parallel split shadow map technique. Is anyone using
PSSM currently and have any suggestions?
I am presently using LiSPSM, it works pretty well but I since I am
rendering a large outdoor scene I find that
Hi,
Sorry for not answering before but I've been away from the computer.
Regarding osg::BufferObject, in my OSG version (2.8.3) there is an
Extensions class declared inside osg::BufferObject. Of course you can
replace it with GLEW, but probably the other compile error is also
related to the
Thank you very much Michael,
your fix solved the timing issue.
Any idea/suggestion about the wrong initial-pose problem? (it happen with
the humanoid.fbx model available with the FBX SDK).
Regards.
Alessandro
On Tue, Jan 18, 2011 at 11:12 AM, Michael Platings mplati...@gmail.comwrote:
Hi
Hi Juan,
I managed to make some progress.
- I replaced osg::BufferObject::Extensions with GLEW
- I changed the other offending expression:
generateTextureObject(contextID, GL_TEXTURE_BUFFER_EXT);
to
generateTextureObject(this, contextID, GL_TEXTURE_BUFFER_EXT);
Things compile fine.
I
Hi,
Thanks Robert. I also saw a 'osgmovie' sample along with other examples built
on OSG 2.9.10. When I hit a 'osgmovie --help', I found an option '--stereo'.
Will this be any simpler than using 'osgstereoimage' ?
Thank you!
Cheers,
Vijay
--
Read this topic online here:
I figured out why texelFetch wasn't being compiled successfully.
1) I forgot the last argument 2) I last tried on AMD/ATI hardware, and the GLSL
compiler on this platform doesn't seem to actually recognize 'texelFetch'...
Now moving on with my tests.
--
Read this topic online
On 01/17/2011 09:27 AM, Jean-Sébastien Guay wrote:
I compiled OSG with the NDK, it was pretty easy. You'll need the
modified NDK that has support for RTTI, exceptions and a more complete
standard library, which you can find here:
http://smartctl.net/android/ndk-r4.php
Just curious,
Has
Hi Fred,
I have never used TBOs before. How do you use your new class?
Is the following correct?
Code:
// Creation
osg::TextureBuffer *tb = new osg::TextureBuffer();
// This will create a buffer of 300 * 4 bytes = 1200 bytes
osg::Image *image = new osg::Image();
image-allocateImage(300
Hi Jason,
Has anybody tried a build with the NDK r5 yet? It's supposed to have an
optional STL that supports RTTI, exceptions, etc. It'd be nice to not
require a 3rd-party NDK to compile OSG.
I haven't tried it yet. It was in my plans but Android development is
not part of my normal job,
Skylark wrote:
Hi David,
You don't recall by chance any fixes that were made after the OSG 2.8.1
release based on resizing issues?
Not off the top of my head, no. It might be interesting to set a
breakpoint in the resize event handler and see if it ever gets there
when it
Great, I've bumped my submission so hopefully it'll be in osg trunk soon.
Re: poses, they have been a complete nightmare to get working so far, and
yet there are still a few cases that don't work. If you can find what's
going on with humanoid.fbx then you'll be my hero! I may be able to help
more
24 matches
Mail list logo
