Re: [osg-users] How to generate fixed alpha value?

[Julien Valentin]

Hi Judy
there's no such thins as pseudo-random generator in glsl itself but you can 
code it for ex:Linear Congruent Generators : 
https://math.stackexchange.com/questions/337782/pseudo-random-number-generation-on-the-gpu
I haven't tested so give us experience feedbacks about this func

(Personnally I generally export random values collected in a image with CPU 
rand() func into a texture and sample it in the shader with gl_Instance_id )

Cheers


xdfanfan wrote:
> Hi all,
> Now，I have a flt. model with itself texture，but the internal format of the 
> texture is RGB，not with ALPHA value，so the ALPHA TEST function is disabled.
> My question is how to generate some random fixed alpha value of the texture 
> with the GLSL language，So that I can use the ALPHA TEST function to fufill 
> the point cloud.
> 
> 
> Thanks very much!
> Judy
> 
>  --
> Post generated by Mail2Forum


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=72417#72417





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Call for assistance: Migrating and updating tutorials

[Björn Blissing]

Hi Robert et al,

As said earlier, I have started to experiment with GitHub pages. I discovered 
that it was hard to support both single-page and multi-page documents using 
markdeep (since its limited support for included documents). So having a 
single-page and multi-page document at the same time will not work unless 
everything is in a completely flat directory structure, which will be 
unmaintainable. So I decided to go with a multi-page solution.

I have pushed the current work to a personal repo on GitHub. You can checkout 
the result at: 
https://bjornblissing.github.io/openscenegraph-tutorials

And the corresponding repo is here:
https://github.com/bjornblissing/openscenegraph-tutorials

So far I have built a test skeleton for tutorials. This includes a draft 
version of the table of contents and simple introduction tutorial to see if my 
test is working. I have included a CMakeList.txt file in the root directory 
which can be used to generate build files for the tutorials. 

The only available tutorial as of now is "Basic Geometry".

But before I continue with any more work I would like some community feedback. 
There are many questions that I think should be answered:

* Is this a tutorial format worth pursuing? 
* Is Markdeep the right choice?
* Is CCBY and MIT licenses that should be used for this project?
* What C++ standard should the source code be written in (my suggestion is 
C++98 for maximum compatibility)?

Note: This should not be seen as anything more than a very rough draft of how 
tutorials on GitHub pages could look like. If the community agrees that this is 
the way forward I will continue the work, as well as transfer the repository to 
the main OpenSceneGraph GitHub account. 

Regards,
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=72416#72416





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Slow optimization and OpenFlight

[Andreas Ekstrand]

Hi Robert,

Yes, the model is ineffective in the sense that it has 150 000 separate 
triangles on the same level in the scene graph, that's the nature of 
basic usage of OpenFlight and I guess that's why the plugin applies an 
optimization of its own. But this could be optimized and merged much 
faster before and I'm just looking for a way to get it to behave like 
that again, to keep my software from being slower in a new version.


Some results from VTune, where I have manually filtered and presented 
the top two culprits in 3.5.1 compared to 3.5.8 (where I gave up after 2 
minutes):


3.5.8: TOTAL: 121.4s

 * Registry::read -> Optimizer::optimize ->
   MergeGeometryVisitor::mergeGroup -> Group::removeChildren ->
   OpenThreads::Atomic::operator++ (78.5s)
 * Registry::read -> Optimizer::optimize ->
   MergeGeometryVisitor::mergeGroup -> Group::removeChildren ->
   OpenThreads::Atomic::operator-- (27.4s)

3.5.1: TOTAL: 12.7s

 * Registry::read -> Optimizer::optimize ->
   Optimizer::StateVisitor::optimize -> Node::setStateSet ->
   StateSet::~StateSet -> StateSet::clear ->
   StateAttribute::removeParent (2.4s)
 * Registry::read -> Optimizer::optimize ->
   Optimizer::MergeGeodesVisitor::mergeGeodes -> Node::~Node ->
   Node::setStateSet -> StateAttribute::removeParent (2.2s)

The MergeGeometryVisitor was applied in 3.5.1 as well but didn't take 
more than about 0.06s. I guess the 3.5.1 results are generally less 
interesting but at least they show that MergeGeometryVisitor was not a 
problem there.


I don't know if this gives you some ideas directly or if we need to keep 
digging. I will have another look shortly either way, but of course 
hoping for you or someone else to come up with some bright ideas to 
shorten the time to fixing this problem.


Regards,
Andreas


On 2017-11-19 16:28, Robert Osfield wrote:

HI Andreas,

I haven't had a chance to dig further.

One curious thing I noticed is that when I enabled verbose debug
output there was lots of buffer objects being created and destroyed
during the optimisation step.  osg::Drawable now assigns
VetextArrayState and VBO's by default for osg::Geometry - this is
required to make VAO support possible.  The large number of these
operations suggest lots of creation and merging of osg::Geometry for
this dataset.  There is chance tthat this change alone may be causing
a performance slow down.

However, I don't think creation/deletion of osg::Geometry is the crux
of the problem, and may not even be the optimization step - it could
well be down to the nature of the scene graph being created by the
OpenFlight plugin for this dataset.  I suspect the source data is
stored in a way that is really inefficient to handle for real-time.
It might be that the OpenFlight plugin just isn't handling the data
well.

As a general rule, running the Optimizer is a last resort for fixing
really bad datasets, ideally datasets should be created in a form that
is appropriate for decent performance right from the start.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] How to generate fixed alpha value?

[Judy]

Hi all,
Now??I have a flt. model with itself  texture??but the internal format of the 
texture is RGB??not with ALPHA value??so the ALPHA TEST function is disabled.
My question is  how to generate some random fixed alpha value of the texture 
with the GLSL language??So that I can use the ALPHA TEST function to fufill the 
point cloud.


Thanks very much!
Judy___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Slow optimization and OpenFlight

[Robert Osfield]

HI Andreas,

I haven't had a chance to dig further.

One curious thing I noticed is that when I enabled verbose debug
output there was lots of buffer objects being created and destroyed
during the optimisation step.  osg::Drawable now assigns
VetextArrayState and VBO's by default for osg::Geometry - this is
required to make VAO support possible.  The large number of these
operations suggest lots of creation and merging of osg::Geometry for
this dataset.  There is chance tthat this change alone may be causing
a performance slow down.

However, I don't think creation/deletion of osg::Geometry is the crux
of the problem, and may not even be the optimization step - it could
well be down to the nature of the scene graph being created by the
OpenFlight plugin for this dataset.  I suspect the source data is
stored in a way that is really inefficient to handle for real-time.
It might be that the OpenFlight plugin just isn't handling the data
well.

As a general rule, running the Optimizer is a last resort for fixing
really bad datasets, ideally datasets should be created in a form that
is appropriate for decent performance right from the start.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Slow optimization and OpenFlight

[Andreas Ekstrand]

Hi Robert,

Yes, I tried it now and OSG 3.4 loads the model in the same time as 
3.2.1 did. I found a few versions lying around here and concluded that 
something must have happened with the optimization between 3.5.1 where 
it works as before and 3.5.6 where it stalls.


I'll keep digging but please let me know if you find something out.

Regards,
Andreas


On 2017-11-17 17:35, Robert Osfield wrote:

Hi Andreas,

Did you try OSG-3.4.x?  I'm wondering about when the regression in
performance might have happened.

I have downloaded the file and will have a look.

Robert.

On 17 November 2017 at 16:14, Andreas Ekstrand
 wrote:

Hi,

I'm still struggling with migrating from old OSG 3.2.1 to the latest
developer release, now 3.5.8.

I stumbled upon a rather serious performance issue here. When loading an
OpenFlight model with a large number of polygons, the optimization carried
out in the OpenFlight plugin is unacceptably slow in 3.5.8. It seems the
culprit is MergeGeometryVisitor.

Here is an example with 150 000 polygons, it takes about 12s to load in
osgviewer 3.2.1 here and what feels like forever to load in 3.5.8:
https://www.dropbox.com/s/lmapv0iatn20d1q/house_150k.flt

Has anyone seen this before? Any ideas how I can get it to behave like
before?

Regards,
Andreas


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to work with zip archives?

[Robert Osfield]

Hi Michael,

It's probably a decade or more since I did anything with
osgDB::Archive and associated plugins so I'm pretty rusty.  Have a
look at the osgarchive application in
OpeScneneGraph/applications/osgarchive.  It should be case of doing a
osgDB::openArcive(..) then doing readNodeFile() etc on the archive.

The zip plugin does have osgDB::Archive support built into it, but I
haven't tested it for a long time, let me know how you get on,

Robert.

On 18 November 2017 at 12:57, michael kapelko  wrote:
> Hi.
> Can anyone provide example on how to work with zip archives? I see
> there is a zip plugin but I can't find any example with it.
>
> I want to read my zips from memory because I do not read them from
> disk, I have them built into the application.
>
> Any clues?
> Thanks.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org