Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[Andreas Ekstrand]

Hi,

Seems to work fine here!

Win10 Home
CMake 3.16.0-rc3
Visual Studio Express 2013

Regards,
Andreas


On 2020-01-24 20:26, Robert Osfield wrote:

HI All,

Still waiting on feedback on how well 3.6.5-rc2 is working OK.  I'm 
ready to tag 3.6.5 at my end as there are no Issue reported yet that I 
can look into resolving.


If there are no Issue's raised by Monday I'll go ahead and tag 3.6.5 
stable release.


Cheers,
Robert.
--
You received this message because you are subscribed to the Google 
Groups "OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to osg-users+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/756a9af1-c0d5-4795-83fc-773a3d99130b%40googlegroups.com 
.


___
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] Any OSGEdit like apps around?

[Andreas Ekstrand]

Hi Paul,

Take a look at Remo 3D (www.remograph.com), not quite like OSGEdit since 
it's based on OpenFlight, but it supports the formats of osg and a 
subset of its features.


Regards,
Andreas


On 2019-10-09 04:09, Paul Leopard wrote:

Hi,

I’ve seen a lot of ten year old info on OSGEdit and I assume that it is now 
defunct since the git hub is dormant. However, the pics I’ve seen of it look 
pretty cool. Are there any active projects around that do the same thing? Looks 
like it would be a good tool for prototyping scene graphs

Thank you!

Cheers,
Paul


things are more like they are now than they have ever been before

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





___
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] osgposter through Task Scheduler

[Andreas Ekstrand]

Thanks Chris! Guess I haven't googled generally enough - will look 
around for more less-specific solutions.

/Andreas

On 2019-07-04 01:15, Chris Djali wrote:

Hi,

I don't want to be the guy that says "Go away and Google your problem", but I 
was curious and searched for OpenGL on headless Windows and saw a few results where 
people had managed to do it. Even if you don't find something compatible with your 
situation, you're likely to find more and better answers on a less-specific mailing list.

Sorry I couldn't give an actual answer,
Chris

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





___
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] osgposter through Task Scheduler

[Andreas Ekstrand]

Hi,

Doesn't anyone have an idea about this? Basic question is, how can one 
retrieve a valid context without logging in to Windows? Is it even 
possible? I guess this problem isn't OSG-specific but I would have 
guessed that someone here had come across this before.


Even if I enable auto-login, it won't allow for remote desktop login 
since you're logged out again after such a session - this makes it hard 
to log in remotely to check the progress of headless process servers.


Regards,
Andreas


On 2019-06-16 21:17, Andreas Ekstrand wrote:

Hi,

I'm having problems with the osgposter example in Windows, or more 
precisely something similar I'm developing but the problem is easier 
to reproduce with osgposter. In my simple reproduction of the problem 
I'm trying to render an image automatically at computer startup by 
calling osgposter (inactive mode) from a Python script (os.system) 
activated as a task from Task Scheduler in Windows 10. But it seems to 
fail to fetch a valid OpenGL context. I have tried all rendering types 
in osgposter - fb, fbo, pbuffer and pbuffer-rtt.


The script works fine when started manually or when the task is set to 
start only when the user is logged on. But when activated as a task at 
computer startup whether user is logged on or not, it refuses to 
render anything. It just gets stuck in an infinite loop in the 
PosterPrinter class since FrameStamp::getFrameNumber() returns 0.


Before that, View::setUpViewInWindow results in the following messages 
if OSG_NOTIFY_LEVEL is set to DEBUG:

(...)
SingleWindow::configure - GraphicsWindow has not been created 
successfully.

(...)
Viewer::realize() - No valid contexts found, setting up view across 
all screens.

(...)
SingleWindow::configure - GraphicsWindow has not been created 
successfully.

(...)
Viewer::realize() - failed to set up any windows

Does anyone know how to get this working without having to log on to a 
Windows user?  Should it work? I have a GeForce GT 710 with the latest 
drivers. Actually, I tried adding opengl32.dll from the Mesa3D library 
to the same folder as osgposter.exe to make it work when manually 
executed while logged on through Remote Desktop. It did the trick, but 
not when activated from Task Scheduler.


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] osgposter through Task Scheduler

[Andreas Ekstrand]

Hi,

I'm having problems with the osgposter example in Windows, or more 
precisely something similar I'm developing but the problem is easier to 
reproduce with osgposter. In my simple reproduction of the problem I'm 
trying to render an image automatically at computer startup by calling 
osgposter (inactive mode) from a Python script (os.system) activated as 
a task from Task Scheduler in Windows 10. But it seems to fail to fetch 
a valid OpenGL context. I have tried all rendering types in osgposter - 
fb, fbo, pbuffer and pbuffer-rtt.


The script works fine when started manually or when the task is set to 
start only when the user is logged on. But when activated as a task at 
computer startup whether user is logged on or not, it refuses to render 
anything. It just gets stuck in an infinite loop in the PosterPrinter 
class since FrameStamp::getFrameNumber() returns 0.


Before that, View::setUpViewInWindow results in the following messages 
if OSG_NOTIFY_LEVEL is set to DEBUG:

(...)
SingleWindow::configure - GraphicsWindow has not been created successfully.
(...)
Viewer::realize() - No valid contexts found, setting up view across all 
screens.

(...)
SingleWindow::configure - GraphicsWindow has not been created successfully.
(...)
Viewer::realize() - failed to set up any windows

Does anyone know how to get this working without having to log on to a 
Windows user?  Should it work? I have a GeForce GT 710 with the latest 
drivers. Actually, I tried adding opengl32.dll from the Mesa3D library 
to the same folder as osgposter.exe to make it work when manually 
executed while logged on through Remote Desktop. It did the trick, but 
not when activated from Task Scheduler.


Regards,
Andreas

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

Re: [osg-users] Geometries disappearing at optimization

[Andreas Ekstrand]

Hi Robert,

Excellent, works like a charm here - thanks for fixing this so quickly.

Regards,
Andreas

On 2018-04-02 15:18, Robert Osfield wrote:

Hi Andreas,

I have  checked in a fix to master and 3.6 branch.

Could you test with your models to make sure we are working fine.

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

Re: [osg-users] OpenSceneGraph-3.6.0 release candidate 3 tagged

[Andreas Ekstrand]

Hi Robert,

Great to see the 3.6 release getting ready, builds fine here on VS 
Express 2013 64-bit. I hope my recent submission to the osgjs plugin 
wasn't too late for the final 3.6 release.


Regards,
Andreas


On 2018-03-30 18:59, Robert Osfield wrote:

Opps, accidentally pressed send somehow...

On 30 March 2018 at 17:54, Robert Osfield  wrote:

I have just tagged 3.6.0-rc3:

So here's the rest of the my message :-)


https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.0-rc3

Just a small tweak to the constness of a couple
osgTerrain::TerrainTechnique methods and a fix to osgText to enable it
to work with GL clipping.

As usually I'd appreciate testing out in the community, both build and
runtime testing.  Please report success/failure so we know how well
the code base is converging towards the final 3.6.0 release.

Cheers,
Robert.

-- Changes since rc3 are:

ri, 30 Mar 2018 16:34:01 +0100
Author : Robert Osfield
Fixed build with OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION set to OFF

Fri, 30 Mar 2018 15:27:35 +0100
Author : Robert Osfield
Added suport for writing to gl_ClipVertex

Fri, 30 Mar 2018 15:16:45 +0100
Author : Robert Osfield
To osgclipe example added --text textstring and --simple command line
options to test mixing text and clipping

Fri, 30 Mar 2018 12:39:52 +0100
Author : Robert Osfield
Changed Layer::get*Value(..) methods to const

Thu, 29 Mar 2018 11:38:04 +0100
Author : Robert Osfield
Fixed double calling of TerrainTechnique::init().

Thu, 29 Mar 2018 11:35:34 +0100
Author : Robert Osfield
Maded TerrainTechnique::setTerrainTile(..), addNeighbour(..),
removeNeighbour(..) and containsNeighbour(..) virtual and public to
enable implementation of TerrainTechnique that act as a facade to
actual TerrainTechnique implementations.
___
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] PIXEL_SIZE_ON_SCREEN And RangeList of osgb file

[Andreas Ekstrand]

Hi Mouming,

With PIXEL_SIZE_ON_SCREEN the specified ranges describe the size in 
pixels of the PagedLOD's bounding sphere. So in your case, when it's far 
away and occupies 0 - 1293 pixels (e.g. 300), the first child is shown, 
i.e. the geometry directly beneath the PagedLOD - no filename is 
specified for the first range. When you get closer it occupies 1293 - 
1e+030 pixels (e.g. 2) and the specified 
Tile_050_050_L21_0.osgb, which should be more detailed, is 
loaded as specified as the second range.


I was under the impression that it uses the bounding sphere diameter in 
pixels but now that I looked more closely I can see in 
CullingSet::pixelSize where it all boils down that it seems to relate to 
the radius instead. Someone more knowledgeable can certainly comment on 
this, as well as the priority offset and scale specified by the 
PriorityList, it's probably some kind of local LOD scale?


Regards,
Andreas


On 2018-01-11 02:42, Mouming Ning wrote:

Hi,

my osgb's "head" is like this:

osg::PagedLOD {
   UniqueID 1
   CenterMode USER_DEFINED_CENTER
   UserCenter -1619.41 -187.445 1047.71 40.4089
   RangeMode PIXEL_SIZE_ON_SCREEN
   RangeList 2 {
 0 1293.08
 1293.08 1e+030
   }
   DatabasePath TRUE "D:\\Tile_050_050/"
   RangeDataList 2 {
 ""
 "Tile_050_050_L21_0.osgb"
   }
   PriorityList 2 {
 0 1
 0 1
   }

My problem is that  how the rangelist correspond to the pixel size on screen?
such as the pixel size is 1300,then this osgb is display on the screen?but when 
the pixel size is 300,then what will happen?? or 2,what will happen??

Another question is that what's meaning of PriorityList?? What is it used for ??

Thank you!

Cheers,
Mouming

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





___
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] createVertexArrayState gives unresolved external symbol

[Andreas Ekstrand]

Hi Robert,

It was in the linking of my application with OSG. But I found the reason 
just now, I needed to copy the include folder to the build folder for 
some reason, and didn't update it between 3.5.8 and 3.5.9. So I guess 
the method had a slight change in its signature. It's fine now, sorry 
for crying wolf. :-)


/Andreas


On 2017-12-01 14:40, Robert Osfield wrote:

Hi Andreas,

Is this linking of the OSG itself. or your application with the OSG?

Robert.

On 1 December 2017 at 13:15, Andreas Ekstrand
<andreas.ekstr...@remograph.com> wrote:

Hi,

When linking with 3.5.9 in Visual Studio 2013, I get a an unresolved
external symbol for Drawable::createVertexArrayState:

error LNK2001: unresolved external symbol "protected: virtual class
osg::VertexArrayState * __cdecl osg::Geometry::createVertexArrayState(class
osg::RenderInfo &)const "
(?createVertexArrayState@Geometry@osg@@MEBAPEAVVertexArrayState@2@AEAVRenderInfo@2@@Z)

Can't see why though, it's inline but defined properly in base class
Drawable header. Does anyone have the same problem or a suggested solution?

/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

[osg-users] createVertexArrayState gives unresolved external symbol

[Andreas Ekstrand]

Hi,

When linking with 3.5.9 in Visual Studio 2013, I get a an unresolved 
external symbol for Drawable::createVertexArrayState:


error LNK2001: unresolved external symbol "protected: virtual class 
osg::VertexArrayState * __cdecl 
osg::Geometry::createVertexArrayState(class osg::RenderInfo &)const " 
(?createVertexArrayState@Geometry@osg@@MEBAPEAVVertexArrayState@2@AEAVRenderInfo@2@@Z)


Can't see why though, it's inline but defined properly in base class 
Drawable header. Does anyone have the same problem or a suggested solution?


/Andreas

___
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]

Sounds great, Robert! The latest master builds fine here.
/Andreas


On 2017-11-27 17:47, Robert Osfield wrote:

On 27 November 2017 at 16:39, Andreas Ekstrand
<andreas.ekstr...@remograph.com> wrote:

Thanks Robert! Works fine here as well, and I think the line of least
resistance was the right way this time.

Any plans on a 3.5.9 release soon? I'm now facing the problem of either
waiting until the next release, or basing my software on 3.5.8 with this
modification and thus implicitly recommending users to use 3.5.8 to be
compatible but with the implication that their OpenFlight models might be
load slowly...

I was planning to tag 3.5.9 in the next day or so.  There isn't any
major feature I'm waiting on, so as long as it compiles and has no
regressions I can tag it right away,

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]

Thanks Robert! Works fine here as well, and I think the line of least 
resistance was the right way this time.


Any plans on a 3.5.9 release soon? I'm now facing the problem of either 
waiting until the next release, or basing my software on 3.5.8 with this 
modification and thus implicitly recommending users to use 3.5.8 to be 
compatible but with the implication that their OpenFlight models might 
be load slowly...


/Andreas


On 2017-11-27 17:25, Robert Osfield wrote:

Hi Andreas,

I have checked in a refactor of MergeGeometry visitor that makes it
work properly with groups containing any type of nodes, and avoids the
O(N^2) removChild() usage.  In the end I took the line of least
resistance and just used the approach of removing all children and
adding back the ndoes.

On 27 November 2017 at 15:56, Andreas Ekstrand
<andreas.ekstr...@remograph.com>  wrote:

Yes, you can argue that the dataset is awful, but it's actually just storing
150k triangles on one graph level, as separate OpenFlight face records,
which is what the OpenFlight file format offers if you don't use its
specific mesh nodes that aren't supported by all tools and don't offer full
control of each triangle. OpenFlight is a modeling file format which is
surely not visualization-friendly. I think the OpenFlight plugin simply uses
the Optimizer to convert this to a dataset for effective visualization
instead of converting to a more optimal scene graph to start with - a choice
that I can't really say if it's good or bad, but the Optimizer should of
course handle bad data in the best way possible.

No need to argue whether it's awful or not, there isn't any debate
when it comes to real-time performance : this particular database is
stored in the worst possible way for memory utilization and
performance

Use of the osgUtil::Optimizer is a very crude fix for bad databases.
It's far better to just create a scene graph in an efficient form
right from the start.  Optimizing bad databases at best leads to
fragment memory, it really is just papering over cracks and is
unlikely to ever produce optimal databases.



The main issue for me though, is that OSG handles this dataset in a much
slower way than before, hence my re-introduction of the previous
optimization. But you're completely right, and I realize now, that other
nodes than drawables aren't handle correctly. I haven't gotten used to
drawables being nodes yet...

So the fact that the OpenFlight plugin creates a non-optimal scene graph and
then uses the Optimizer itself to fix this is probably a separate and larger
problem - if it indeed is a problem.

Yep, big topic.  I'm familiar with the problems that the OpenFlight
loader generates, but less so with Creator or other tools that
generate the content.  I'd much rather the OpenFlight loader builds
more efficient database to start with rather than rely upon the
Optimizer to fix problems once the data is loaded.


But I believe it's necessary to at
least get MergeGeometryVisitor to behave as fast as before, either by
modifying my fixes or by rewriting parts of it. I hope you will find the
time to decide on this soon, and please let me know if I can help!

The fix I have checked in master:

 
https://github.com/openscenegraph/OpenSceneGraph/commit/bc4a9d9dd0158e1e99d0ca1d1d95ef204220a560

With performance testing of just the merge geometry on your house
dataset I saw a 70sec merge geometry before, and 0.1 sec merge after
my changes.

I've got plenty of other stuff to get on with so I'll assume this
issue is now resolved.

Cheers,
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

Re: [osg-users] Slow optimization and OpenFlight

[Andreas Ekstrand]

Hi Robert,

Thanks for looking into this!

Yes, you can argue that the dataset is awful, but it's actually just 
storing 150k triangles on one graph level, as separate OpenFlight face 
records, which is what the OpenFlight file format offers if you don't 
use its specific mesh nodes that aren't supported by all tools and don't 
offer full control of each triangle. OpenFlight is a modeling file 
format which is surely not visualization-friendly. I think the 
OpenFlight plugin simply uses the Optimizer to convert this to a dataset 
for effective visualization instead of converting to a more optimal 
scene graph to start with - a choice that I can't really say if it's 
good or bad, but the Optimizer should of course handle bad data in the 
best way possible.


The main issue for me though, is that OSG handles this dataset in a much 
slower way than before, hence my re-introduction of the previous 
optimization. But you're completely right, and I realize now, that other 
nodes than drawables aren't handle correctly. I haven't gotten used to 
drawables being nodes yet...


So the fact that the OpenFlight plugin creates a non-optimal scene graph 
and then uses the Optimizer itself to fix this is probably a separate 
and larger problem - if it indeed is a problem. But I believe it's 
necessary to at least get MergeGeometryVisitor to behave as fast as 
before, either by modifying my fixes or by rewriting parts of it. I hope 
you will find the time to decide on this soon, and please let me know if 
I can help!


Regards,
Andreas


On 2017-11-27 14:27, Robert Osfield wrote:

HI Andreas,

I gave up the valgrind tool=callgrind because it was taking too long
to complete.  What I did gleen from it was that the run confirms that
removeChildren() is a bottleneck.

To get some context to why it's a bottlenck I put in some stats output
from the MergeGeometryVisitor::mergeGroup(..) and got the following
output:

$ osgconv house_150k.flt test3.osgb
Optimizer::MergeGeometryVisitor::mergeGroup() 148976
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=
 duplicateList.size()=2324
Data written to 'test3.osgb'.

What this tells us that this dataset generated by the OpenFlight
loader is truly dreadful.  It's just appalling how it's handling the
house_150k.flt database.  I don't know if this can be traced back to
what the OSG's OpenFlight plugin is doing or whether the tool that
generated the .flt file is just has a completely awful export tool.
What I can say is that the fact that the OSG can handle at all such a
brain dead messed up dataset is a miracle.

The best way to resolve this issue is to refactor the
MergeGeometryVisitor so it handles these really bad datasets with more
grace, avoiding the pitfalls of an O(N^2) algorithm.

Having the core OSG "fix" really bad data is not a proper resolution.
it doesn't fix the fact the the OpenFlight loader is generating such a
dreadful scene graph.  It might be that the OpenFlight loader is just
doing what the source database is tell it to do and isn't to blame,
but like the change MergeGeometryVisitor, it may be worth catching
this dreadful datacase on load and never generating the broken scene
graph.  It's better to fix problems like this early rather than let it
get all the way to the osgUtil::Optimizer to patch fix things up, the
early it is done the less memory will be used and less memory will be
fragmented and better the performance will be.

I am afraid I just don't have the time to go chasing fixes to awful
3rd party data, I already have enough core OSG issues to do that
unpaid without taking on more.  I will resolve the
MergeGeometryVisitor O(N^2) issue but improving the OpenFlight 

Re: [osg-users] Slow optimization and OpenFlight

[Andreas Ekstrand]

Forgot to mention that the geometry before and after optimization is 
identical in the different OSG versions, so the optimizer accomplishes 
the same thing, it just takes about 10 times longer.

/Andreas


On 2017-11-24 14:10, Andreas Ekstrand wrote:

Hi,

Some more results from my investigations:

Back in February, the MergeGeometryVisitor was changed to be applied 
on Group instead of Geode by Jannik Heller (in CC). This has resulted 
in substantially longer optimization time of my loaded OpenFlight 
files with a large number of polygons. I assume it's a general 
performance problem with many geodes/geometries.


The removeChild call from MergeGeometryVisitor ::mergeGroup is the 
main culprit and takes about 87% of the time:

group.removeChild(*ditr);

Does Robert or Jannik have any idea about this? I don't feel 
comfortable enough with the code to make any changes, but this 
prevents me from upgrading my software to the latest OSG version, 
while I can't go back either since I need other fixes in 3.5.8. So I'm 
a bit stuck and would appreciate any help!


Regards,
Andreas


On 2017-11-19 17:13, Andreas Ekstrand wrote:

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 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] Slow optimization and OpenFlight

[Andreas Ekstrand]

Hi,

Some more results from my investigations:

Back in February, the MergeGeometryVisitor was changed to be applied on 
Group instead of Geode by Jannik Heller (in CC). This has resulted in 
substantially longer optimization time of my loaded OpenFlight files 
with a large number of polygons. I assume it's a general performance 
problem with many geodes/geometries.


The removeChild call from MergeGeometryVisitor ::mergeGroup is the main 
culprit and takes about 87% of the time:

group.removeChild(*ditr);

Does Robert or Jannik have any idea about this? I don't feel comfortable 
enough with the code to make any changes, but this prevents me from 
upgrading my software to the latest OSG version, while I can't go back 
either since I need other fixes in 3.5.8. So I'm a bit stuck and would 
appreciate any help!


Regards,
Andreas


On 2017-11-19 17:13, Andreas Ekstrand wrote:

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 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

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
<andreas.ekstr...@remograph.com> 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

[osg-users] Slow optimization and OpenFlight

[Andreas Ekstrand]

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

Re: [osg-users] Invisible light points

[Andreas Ekstrand]

Hi Robert,

Thanks a lot for your efforts! And great to see that it made it into 
3.5.7, so I will use this release from now on.


Regards,
Andreas


On 2017-10-06 19:06, Robert Osfield wrote:

Hi Andreas,

I have just checked in a fix to src/osg/VertexArrayState.cpp to 
resolve this light point bug.


Commit is:
https://github.com/openscenegraph/OpenSceneGraph/commit/4906844ea76054a83ad96afb8439dd521db456ff

This is checked into OSG master.

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

Re: [osg-users] Cloning text

[Andreas Ekstrand]

Thanks for the suggestions, Robert! I was just investigating such 
possibilities, shows I'm on the right track...

/Andreas

On 2017-09-22 12:13, Robert Osfield wrote:

Hi Andreas.

On 22 September 2017 at 09:40, Andreas Ekstrand 
<andreas.ekstr...@remograph.com 
<mailto:andreas.ekstr...@remograph.com>> wrote:


I'm using osgText to show vertex numbers. Often enough it's only
0,1,2 for triangles but it can be several hundred thousands of them.

It's never been optimal, I know - and I guess this is the time to
do something about it, I will look into an alternative way without
osgText. Any suggestions are welcome!


On the OSG side I steadily shifting osgText to using shaders for 
effects and simplifying the CPU side.  Not all the way there yet but 
that's the direction I'm going with it.  Simplifying the CPU side will 
mean less custom data manipulation that is different frrom 
osg::Geometry that just pushes arrays and primitives to GL.  With 
these evolution of osgText the overhead for creating new text should 
be lower.


However, osgText it will always be a general purpose text 
implementation rather than a highly tuned for a specific purpose.  In 
your case it might be simpler to do some specifically your task.  If 
you have just 0..9 characters and a limited number of characters you 
start thinking about doing far more on the GPU.


For instance you could use a single textured quad for each label, 
passing in the characters to render via a uniform array or packed 
uniforms and have a shader work out what texture coordinates into the 
glyph texture atlas to use to render each character, then in the 
fragment shader get the appropriate samples for each character.  I 
have used this approach on client project to make a very lightweight 
system for rendering labels, it was a closed source project so not 
something I can share the implementation, but it does at least show it 
works.


Another approach you could take is just create your own osg::Geometry 
and reuse the osgText::Font/osgText::GlyhTexture. In the end basic 
rendering of text is just texture quads, osgText can be used to 
provide the texture atlas you need so most of the awkward work is done 
for you already.


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

Re: [osg-users] Cloning text

[Andreas Ekstrand]

Hi,

I'm using osgText to show vertex numbers. Often enough it's only 0,1,2 
for triangles but it can be several hundred thousands of them.


It's never been optimal, I know - and I guess this is the time to do 
something about it, I will look into an alternative way without osgText. 
Any suggestions are welcome!


Regards,
Andreas


On 2017-09-08 17:09, Robert Osfield wrote:

Hi Andreas,

I am bit surprised by the extra memory footprint, as I'm currently 
working on osgText::Text I don't want to start diving into code that 
may well disappear once my work is complete.  The new osgText::Text 
implementation relies upon shaders to do outline and shadows rather 
than multipass and should simplify the internals a bit.  Given this 
the balance of memory overhead is likely to change.


As a general comment, creating a 150,000 copies of an object is 
something that raise a red flag - suggesting that you are working 
around an issue that may well be better solved with a different 
approach, perhaps not using osgText::Text at all.


Could you explain from a higher level what you are wanting to do with 
all these text labels?


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

Re: [osg-users] Cloning text

[Andreas Ekstrand]

Hi,

I revisited my osgText performance issue by measuring the time for 
copying text.


With some 150,000 copies of my VertexNumber class inheriting from 
osgText::Text, I ended up with roughly the following figures using OSG 
3.5.6, compared to my previous solution using OSG 3.2.1, calling the 
osgText::TextBase copy constructor from my copy constructor (skipping 
over osgText::Text copy constructor) and copying the 
_textureGlyphQuadMap instead of calling the slower 
computeGlyphRepresentation.


3.2.1 without the "trick" above:
40 - 70% slower compared to 3.2.1 with trick

3.5.6 (obviously without the trick):
50 - 90% slower compared to 3.2.1 with trick
10 - 30% slower compared to plain 3.2.1 without trick

Furthermore, in 3.5.6 my application requires about 37% more RAM with 
this number of texts, compared to 3.2.1 (both with and without the 
trick), but only about 4% more without the texts created.


I'm creating and caching new text instances per vertex number in the 
model. Since there are mostly triangles, I'm getting 0,1,2 but also 
occasional other numbers up to 7 for special polygons. For a situation 
like this, with a large number of texts from a small number of cached 
originals, what would be the recommended approach? Maybe osgText isn't 
suitable at all?


Regards,
Andreas


On 2017-08-18 11:38, Robert Osfield wrote:

Hi Andreas,

In my rewrite of osgText my approach was that the internal 
implementation details aren't meant to be something that users need to 
meddle with.


The fact that you are needing to meddle with the internal details to 
workaorund performance issues in your usage case suggest an issue with 
basic performance/flexibility,  The new implementation might change 
this performance/flexibility side so perhaps your local changes might 
not be needed.


If the new osgText doesn't provide the performance you need for your 
usage case perhaps it could be optimized to handle them.  Creating an 
example that illustrates the usage case which highlights the issues 
would be a good first step if you feel this approach has promise.


Finally, I'm open to small tweaks to the API allow easier subclassing. 
However, this isn't my preferred approach as any changes to the 
internals later would then break end user code that relies upon it - 
exactly the problem you are facing now...


Robert.

On 18 August 2017 at 09:14, Andreas Ekstrand 
<andreas.ekstr...@remograph.com 
<mailto:andreas.ekstr...@remograph.com>> wrote:


Hi,

With OSG 3.2.1 I have been able to do fast shallow cloning of
osgText::Text in my own subclass, copying the _textureGlyphQuadMap
instead of calling computeGlyphRepresentation, since the latter is
a slow operation for my thousands of texts.

In OSG 3.5.6 this isn't possible, I guess due to a private
GlyphQuads::operator=. So I'm looping through _textureGlyphQuadMap
in my copy constructor and copy its glyphs and primitives
separately instead. But I can't see my copied text at all! If I
save it out to an .osg or .osgt file it's visible in osgviewer.

I guess setting GlyphQuads::operator= private was deliberate, so
can someone explain how I can accomplish fast text cloning in OSG
3.5.6 or optimize it somehow?

Regards,
Andreas


___
osg-users mailing list
osg-users@lists.openscenegraph.org
<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-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] Invisible light points

[Andreas Ekstrand]

Strange, thought the reply-to address was set from osg-users...this was 
what I accidentally sent to Robert only:


Hi Robert,

Thanks for your reply, I realize you're busy with 3.4.1 right now. But 
if you can find the time to look into this I have also attached a simple 
example reproducing the issue in code. Commenting in adding of the geode 
will hide the light points.


/Andreas


On 2017-08-18 11:12, Robert Osfield wrote:

Hi Andreas,

On 18 August 2017 at 08:30, Andreas Ekstrand 
<andreas.ekstr...@remograph.com 
<mailto:andreas.ekstr...@remograph.com>> wrote:


Did someone manage to reproduce this problem? Any suggestions are
welcome, I really don't understand what's happening here...


I haven't had a chance to test the issue yet.  In the latest OSG there 
are rewrites of various parts of the OSG to move fully over to use 
vertex arrays and supporting VAO's, my guess is this work touched upon 
osgSim::LightPoint* functionality and introduced a regression, as to 
what this might be I can't say without reproduce the issue and 
investigating the related code.


In general the behaviour you describe sounds like vertex array state 
that is not being set up correctly so the values used by the driver 
are just the last ones to be set rather than the one intended.


Robert.


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


#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char **argv)
{
  osgViewer::Viewer viewer;
  osg::ref_ptr topGroup = new osg::Group();

  osg::ref_ptr lpNode = new osgSim::LightPointNode();
  lpNode->addLightPoint(osgSim::LightPoint(osg::Vec3(-10.0f, 0.0f, 0.0f), 
osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f)));
  lpNode->addLightPoint(osgSim::LightPoint(osg::Vec3(10.0f, 0.0f, 0.0f), 
osg::Vec4(0.0f, 1.0f, 0.0f, 1.0f)));
  topGroup->addChild(lpNode);

  osg::ref_ptr geode = new osg::Geode();
  osg::ref_ptr geometry = new osg::Geometry();
  osg::ref_ptr vertices = new osg::Vec3Array();
  vertices->push_back(osg::Vec3(-1.0f, -1.0f, 0.0f));
  vertices->push_back(osg::Vec3(1.0f, -1.0f, 0.0f));
  vertices->push_back(osg::Vec3(1.0f, 1.0f, 0.0f));
  vertices->push_back(osg::Vec3(-1.0f, 1.0f, 0.0f));
  geometry->setVertexArray(vertices);
  geometry->addPrimitiveSet(new osg::DrawArrays(GL_QUADS, 0, 4));
  geode->addDrawable(geometry);
  //topGroup->addChild(geode);

  viewer.setSceneData(topGroup);
  viewer.realize();
  return viewer.run();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Cloning text

[Andreas Ekstrand]

Hi,

With OSG 3.2.1 I have been able to do fast shallow cloning of 
osgText::Text in my own subclass, copying the _textureGlyphQuadMap 
instead of calling computeGlyphRepresentation, since the latter is a 
slow operation for my thousands of texts.


In OSG 3.5.6 this isn't possible, I guess due to a private 
GlyphQuads::operator=. So I'm looping through _textureGlyphQuadMap in my 
copy constructor and copy its glyphs and primitives separately instead. 
But I can't see my copied text at all! If I save it out to an .osg or 
.osgt file it's visible in osgviewer.


I guess setting GlyphQuads::operator= private was deliberate, so can 
someone explain how I can accomplish fast text cloning in OSG 3.5.6 or 
optimize it somehow?


Regards,
Andreas

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

Re: [osg-users] Invisible light points

[Andreas Ekstrand]

Did someone manage to reproduce this problem? Any suggestions are 
welcome, I really don't understand what's happening here...

/Andreas

On 2017-08-04 13:12, Andreas Ekstrand wrote:

Hi,

I recently moved from OSG 3.2.1 to 3.5.6 and now I have problems with 
light points going invisible if rendered together with other geometry.


I managed to reproduce in a small test case - have a look at the 
attached lp and lp_poly models (both in 3.5.6 osgt and deprecated osg 
which I find easier to debug). With 3.5.6, I can only see the light 
points in the lp model and not in the lp_poly model - any idea why?


I tried disabling culling, changing render binds, removing all 
StateSets in the osg files. No matter what, it seems the geode causes 
the light points to be invisible. How can I fix this?


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] Invisible light points

[Andreas Ekstrand]

Hi,

I recently moved from OSG 3.2.1 to 3.5.6 and now I have problems with 
light points going invisible if rendered together with other geometry.


I managed to reproduce in a small test case - have a look at the 
attached lp and lp_poly models (both in 3.5.6 osgt and deprecated osg 
which I find easier to debug). With 3.5.6, I can only see the light 
points in the lp model and not in the lp_poly model - any idea why?


I tried disabling culling, changing render binds, removing all StateSets 
in the osg files. No matter what, it seems the geode causes the light 
points to be invisible. How can I fix this?


Regards,
Andreas

Group {
  nodeMask 0x
  cullingActive FALSE
  num_children 1
  Group {
nodeMask 0x
cullingActive FALSE
num_children 1
osgSim::LightPointNode {
  nodeMask 0x
  cullingActive FALSE
  num_lightpoints 2
  minPixelSize 4
  maxPixelSize 14
  maxVisibleDistance2 3.40282e+038
  pointSprite FALSE
  lightPoint {
isOn TRUE
position 0.5 0.5 0.5
color 1 1 1 1
intensity 1
radius 10
blendingMode ADDITIVE
  }
  lightPoint {
isOn TRUE
position 1.5 1.5 0.5
color 1 1 1 1
intensity 1
radius 10
blendingMode ADDITIVE
  }
}
  }
}
Group {
  nodeMask 0x
  cullingActive FALSE
  num_children 2
  Group {
nodeMask 0x
cullingActive FALSE
num_children 1
osgSim::LightPointNode {
  nodeMask 0x
  cullingActive FALSE
  num_lightpoints 2
  minPixelSize 4
  maxPixelSize 14
  maxVisibleDistance2 3.40282e+038
  pointSprite FALSE
  lightPoint {
isOn TRUE
position 0.5 0.5 0.5
color 1 1 1 1
intensity 1
radius 10
blendingMode ADDITIVE
  }
  lightPoint {
isOn TRUE
position 1.5 1.5 0.5
color 1 1 1 1
intensity 1
radius 10
blendingMode ADDITIVE
  }
}
  }
  Geode {
nodeMask 0x
cullingActive FALSE
num_drawables 1
Geometry {
  supportsDisplayList FALSE
  useDisplayList FALSE
  useVertexBufferObjects FALSE
  PrimitiveSets 1
  {
DrawArrays TRIANGLES 0 3
  }
  VertexArray Vec3Array 2
  {
0 1 0
0 -1 0
1 0 0
  }
  ColorBinding PER_PRIMITIVE_SET
  ColorArray Vec4Array 1
  {
1 1 1 1
  }
}
  }  
}
#Ascii Scene 
#Version 148 
#Generator OpenSceneGraph 3.5.6 

osg::Group {
  UniqueID 1 
  Name "lp_poly.osg" 
CullingActive FALSE 
Children 2 {
osgSim::LightPointNode {
  UniqueID 2 
  CullingActive FALSE 
StateSet TRUE {
osg::StateSet {
  UniqueID 3 
  DataVariance STATIC 
RenderBinMode USE_RENDERBIN_DETAILS 
BinNumber 20 
BinName "DepthSortedBin" 
}
  }
LightPointList 2 {
LightPoint {
Position 0.5 0.5 0.5 
Color 1 1 1 1 
Attributes TRUE 0 1 10 
Sector FALSE BlinkSequence FALSE }
LightPoint {
Position 1.5 1.5 0.5 
Color 1 1 1 1 
Attributes TRUE 0 1 10 
Sector FALSE BlinkSequence FALSE }
}
MinPixelSize 4 
MaxPixelSize 14 
MaxVisibleDistance2 3.40282e+038 
}
osg::Geode {
  UniqueID 4 
  CullingActive FALSE 
Drawables 1 {
osg::Geometry {
  UniqueID 5 
  DataVariance STATIC 
SupportsDisplayList FALSE 
UseDisplayList FALSE 
PrimitiveSetList 1 {
osg::DrawArrays {
  UniqueID 6 
  Mode TRIANGLES 
Count 3 
}
  }
VertexArray TRUE {
osg::Vec3Array {
  UniqueID 7 
  BufferObject TRUE {
osg::VertexBufferObject {
  UniqueID 8 
}
  }
Binding BIND_PER_VERTEX 
vector 3 {
0 1 0 
0 -1 0 
1 0 0 
}
}
  }
ColorArray TRUE {
osg::Vec4Array {
  UniqueID 9 
  Binding BIND_PER_PRIMITIVE_SET 
vector 1 {
1 1 1 1 
}
}
  }
}
  }
}
  }
}
#Ascii Scene 
#Version 148 
#Generator OpenSceneGraph 3.5.6 

osg::Group {
  UniqueID 1 
  Name "lp.osg" 
CullingActive FALSE 
Children 1 {
osgSim::LightPointNode {
  UniqueID 2 
  CullingActive FALSE 
StateSet TRUE {
osg::StateSet {
  UniqueID 3 
  DataVariance STATIC 
RenderBinMode USE_RENDERBIN_DETAILS 
BinNumber 20 
BinName "DepthSortedBin" 
}
  }
LightPointList 2 {
LightPoint {
Position 0.5 0.5 0.5 
Color 1 1 1 1 
Attributes TRUE 0 1 10 
Sector FALSE BlinkSequence FALSE }
LightPoint {
Position 1.5 1.5 0.5 
Color 1 1 1 1 
Attributes TRUE 0 1 10 
Sector FALSE BlinkSequence FALSE }
}
MinPixelSize 4 
MaxPixelSize 14 
MaxVisibleDistance2 3.40282e+038 
}
  }
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] PagedLOD glitches

[Andreas Ekstrand]

Thanks, Robert and Chris! I built the quadtree myself and I had indeed 
messed up the scene graph. Doing everything by the book works much 
better, it runs smoothly now.


Regards,
Andreas


On 2016-08-26 17:35, Chris Hanson wrote:
Yeah, something's not right with your scene graph. You shouldn't see 
that behavior if your PagedLODs are structured correctly.


You might add some debugging messages to determine what is happening 
in the PagedLOD node that contains the geometry that disappears in #2, 
as it must be switching to SOME other child during the #2 time period.


You're not using an extra level of indirection like a second PagedLOD 
under the main PagedLOD, are you? Or a Switch or a ProxyNode or 
something else?


What built the quadtree database?
​


___
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] PagedLOD glitches

[Andreas Ekstrand]

Hi Robert,

The glitches are purely visual. I have no overlapping ranges, my problem 
is the opposite - when I'm moving towards a level and the range 
switches, it takes a while to load the high level and the low level is 
switched off. While loading, there is just empty space for a while until 
the high level has been loaded and is visualized.


Attached is an attempt to illustrate the problem. When moving from 
position 1 to 2, the middle level is switched out and although the high 
level is within its range it takes a while to load it, so there is a 
hole until it's finally been loaded in 3. Note that I don't have to move 
the viewer between 2 and 3, just wait for the loading. I would want the 
middle level to be visible until the high level is actually loaded.


Maybe I'm misunderstanding something about PagedLOD, the database pager, 
or how to create quad-tree scene graphs for it to work properly? I have 
only developed these things myself before in other projects, and 
actually not used PagedLOD until now.


Regards,
Andreas


On 2016-08-26 15:58, Robert Osfield wrote:

Hi Andreas,

On 26 August 2016 at 12:09, Andreas Ekstrand
<andreas.ekstr...@remograph.com> wrote:

Is there any way to avoid glitches in the PagedLOD during loading of the
higher level after the lower level has switched out?

Are we talking just a visual glitch or a frame rate drop, or both?


When flying over my
quad-tree terrain the tiles are flickering and the background color is
visible a short while before the higher level has been loaded.

One can of course override and implement logic that waits to switch the
lower level of until the higher has been loaded, but maybe I have missed
some existing setting?

The logic in PageLOD::traverse() that decides between which LOD's to
display depends entirely on the LOD ranges used for each child, if the
ranges are distinct then no two children of a single PageLOD will be
displayed at the same time.

If you built the database such that the PageLOD's overlap a bit then
you have a case where both a lower level of detail and higher level of
detail could be visible at once.  Given your description this sounds
like it may be possibility.  I wouldn't recommend building PageLOD
databases with overlapping LOD range though - they can abut but
shouldn't overlap.

The other possibility might be display latency, or if you have some
kinds of higher level effect for visually blending between LOD levels.

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] PagedLOD glitches

[Andreas Ekstrand]

Hi,

Is there any way to avoid glitches in the PagedLOD during loading of the 
higher level after the lower level has switched out? When flying over my 
quad-tree terrain the tiles are flickering and the background color is 
visible a short while before the higher level has been loaded.


One can of course override and implement logic that waits to switch the 
lower level of until the higher has been loaded, but maybe I have missed 
some existing setting?


Regards,
Andreas

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

Re: [osg-users] Problem reading Openflight file switch node

[Andreas Ekstrand]

Hi,

Our tool is called Remo 3D and is free to use as read-only for purposes 
like this:

http://www.remograph.com/download.php

From what I can see, the model is fine - apart from the medium LOD 
containing an extra small radar geometry, but that probably has nothing 
to do with your problem.


I can confirm that it works in OSG 3.2.1 as well as in 3.4, although 3.4 
seems to group the children in a more optimal way. In which version do 
you observe the problem? If you convert to .osgt or .osg files, make 
sure you have built the osgdb_serializers_osgsim and 
osgdb_deprecated_osgsim plugins as well, since the MultiSwitch is in osgSim.


Regards,
Andreas


On 2015-12-13 18:49, Sebastian Messerschmidt wrote:

Hi Robert,
On 13 December 2015 at 12:44, Sebastian Messerschmidt 
> wrote:


Can you provide a simple model to reproduce the bug?


Tony attached a radar_flt.txt file to his first post in this thread, 
this needs to be renamed to radar.flt.

Thx, I didn't see the original post on my mobile.


I don't have Creator so have no way of knowing whether the OSG's 
OpenFlight plugin is doing the right thing relative to the radar.flt 
that Tony published. I'll have to defer to others in the community 
with access to Creator to check things.
In case you're interested: There is a tool called RemoGraph3D (which 
is OSG-based) which offers a lot of the Creator's functionality.

I'll try to check the model.
Cheers
Sebastian


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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Avoiding texture release

[Andreas Ekstrand]

Hi Robert,

You're right, it was the sheer amount of texels that was the problem. By adding 
polygons using both set of textures in both switch children, I saw that 
performance was bad all the time instead, due to constant swapping. Guess I 
thought I used a better graphics card. :-) I had to scale down to 4096x4096 
which was fine.

Regards,
Andreas

> 30 sep 2015 kl. 16:56 skrev Robert Osfield <robert.osfi...@gmail.com>:
> 
> Hi Andreas,
> 
> I suspect just letting the OSG do it's thing with be just fine, and it's 
> simply the amount of memory on the GPU that these textures take is 
> fundamental problem you need to address.
> 
> Try texture compression on the textures, or try a small pixel format.
> 
> The other approach would be to tile that data up so you have a set of smaller 
> textures each applied to it's own Geode.
> 
> Robert.
> 
>> On 30 September 2015 at 14:25, Andreas Ekstrand 
>> <andreas.ekstr...@remograph.com> wrote:
>> Hi,
>> 
>> I have a switch node with two geodes containing one geometry each, 
>> shallow-copied from the same geometry but with different state sets having 
>> different textures. The textures are large (8192x8192) and this causes a 
>> massive frame drop when switching between the two geodes at runtime. I know 
>> it's the textures causing the hickup since it doesn't happen when not 
>> setting the texture attributes.
>> 
>> I have tried applying a GLObjectsVisitor before adding the geodes to the 
>> switch, and after adding them, setting a 0x node mask. I have tried 
>> applying a TextureVisitor with changeAutoUnref and valueAutoUnref. I have 
>> also tried setting an IncrementalCompileOperation although I don't really 
>> know why. Nothing helps, how can I avoid these frame drops? I guess I want 
>> to avoid a releaseGLObjects happening somewhere?
>> 
>> 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

[osg-users] Avoiding texture release

[Andreas Ekstrand]

Hi,

I have a switch node with two geodes containing one geometry each, 
shallow-copied from the same geometry but with different state sets having 
different textures. The textures are large (8192x8192) and this causes a 
massive frame drop when switching between the two geodes at runtime. I know 
it's the textures causing the hickup since it doesn't happen when not setting 
the texture attributes.

I have tried applying a GLObjectsVisitor before adding the geodes to the 
switch, and after adding them, setting a 0x node mask. I have tried 
applying a TextureVisitor with changeAutoUnref and valueAutoUnref. I have also 
tried setting an IncrementalCompileOperation although I don't really know why. 
Nothing helps, how can I avoid these frame drops? I guess I want to avoid a 
releaseGLObjects happening somewhere?

Regards,
Andreas


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

Re: [osg-users] What tools do you use

[Andreas Ekstrand]

Hi Daniel,

Regarding Remo 3D, it may be of interest that Remograph does have a 
terrain generating software on its way, based upon Remo 3D, QGIS and 
other open-source products. Its current working title is Remo 3D 
Terrain Kit or R3T and it generates 3D terrain from GIS data.


R3T is still an internal product used to generate 3D terrain as a 
service provided to our customers. It will be a fully documented, tested 
and user-friendly external product in the future though. So if you need 
3D terrain generated as a service, Remograph is available. And in a 
hopefully not so distant future, it will be available as a commercial 
product, as moderately priced as Remo 3D. If someone is interested in 
beta testing R3T further ahead, don't hesitate to contact me.


Regards,
Andreas Ekstrand
Remograph


On 2013-09-20 09:20, Daniel Schmid wrote:

Hi all out there

I am trying to build content for our OSG-based driving simulation engine. I 
have some complete terrains (terrain, buildings, streets, vegetation, etc) that 
were build (externally) on a terravista based toolchain.

I was searching the forum to find out what tools people use to generate such 
content showing urban or natural areas, with cities, villages etc. There are 
some discussions about similar subjects...

There are some osg based tools like osgEdit (outdated), osgExplore (view 
only?), Remo3D (commercial, but focused on models, not terrain), Blender 
(export issues?), etc.

I thought it would be worth a thread where people just line up their tool chain 
and what they use for what, starting from generating terrain, to placing roads, 
buildings, vegetation, optimizing, exporting, etc.

There you go!

Regards
Daniel

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





___
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] What tools do you use

[Andreas Ekstrand]

Daniel,

I'm not sure yet about when beta testing will start, but it may be in a 
couple of months. I will add you to the list of beta testers and let you 
know.


Regards,
Andreas


On 2013-09-20 09:51, Daniel Schmid wrote:

Sounds interesting to me. I would be glad if you added me to the list of beta 
testers. When will public beta tests be starting?

Cheers,
Daniel

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





___
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] Display lists and BIND_PER_PRIMITIVE_SET

[Andreas Ekstrand]

Hi,

In the attached .osg file, the center horizontal and vertical lines 
should be red, accomplished by binding colors per primitive set. But 
with useDisplayLists TRUE, all lines are green. Disabling display 
lists will fix the problem, but I'm just curious on why this happens - 
maybe it's too early in the morning and I'm not seeing the 
obvious...please enlighten me.


Regards,
Andreas

Group {
  UniqueID Group_5
  nodeMask 0x
  cullingActive TRUE
  num_children 1
  Geode {
UniqueID Geode_12
nodeMask 0x
cullingActive TRUE
StateSet {
  UniqueID StateSet_13
  rendering_hint DEFAULT_BIN
  renderBinMode USE
  binNumber 0
  binName RenderBin
  GL_LIGHTING OVERRIDE|OFF
}
num_drawables 1
Geometry {
  UniqueID Geometry_14
  useDisplayList TRUE
  useVertexBufferObjects FALSE
  PrimitiveSets 10
  {
DrawArrays LINES 0 2
DrawArrays LINES 2 2
DrawArrays LINES 4 2
DrawArrays LINES 6 2
DrawArrays LINES 8 2
DrawArrays LINES 10 2
DrawArrays LINES 12 2
DrawArrays LINES 14 2
DrawArrays LINES 16 2
DrawArrays LINES 18 2
  }
  VertexArray Vec3Array 20
  {
-20 20 0
-20 -20 0
-10 20 0
-10 -20 0
0 20 0
0 -20 0
10 20 0
10 -20 0
20 20 0
20 -20 0
-20 20 0
20 20 0
-20 10 0
20 10 0
-20 0 0
20 0 0
-20 -10 0
20 -10 0
-20 -20 0
20 -20 0
  }
  ColorBinding PER_PRIMITIVE_SET
  ColorArray Vec4Array 10
  {
0.0 1.0 0.0 1.0
0.0 1.0 0.0 1.0
1.0 0.0 0.0 1
0.0 1.0 0.0 1.0
0.0 1.0 0.0 1.0
0.0 1.0 0.0 1.0
0.0 1.0 0.0 1.0
1.0 0.0 0.0 1
0.0 1.0 0.0 1.0
0.0 1.0 0.0 1.0
  }
}
  }
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Method for Converting FLT files to use DDS Textures

[Andreas Ekstrand]

Hi Karl,

One option could be to script the texture palette reference changes 
using Remo 3D (www.remograph.com) and convert the images using OSG or 
nvdxt from Nvidia DDS Utilities. If you need help with this, feel free 
to e-mail me off the list.


Regards,
Andreas


On 2013-01-25 13:54, Cary, Karl A. wrote:


This isn't a direct OSG question, but one I was hoping people on this 
list might be able to help out with. We have several thousand FLT 
files that use rgbs as textures. Unfortunately we can't convert these 
to ive or osgb files as they are shared with another application that 
is not made in OSG and only supports FLT files. However, both can 
support FLT files using DDS textures to allow for texture compression. 
Through testing we have shown a large improvement by doing this, so we 
want to go that route.


The issue is how to convert all of these FLT files over. We can easily 
batch convert all of the textures, that is not a problem. The issue is 
updating the FLT files themselves to tell them to point to the dds 
texture instead of the rgb texture. Having someone manually open up 
each file and edit the texture names is VERY time consuming. Does 
anyone know of an easy way we could do this through scripting or a 
custom converter or something else? The files will stay named the same 
except for the .rgb will become .dds.


Thanks in advance.

*Karl Cary*

*SAIC*

*Software Developer*

*301-227-5656*



___
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] New Osg Models

[Andreas Ekstrand]

Hi Theuns,

One option is to use Remo 3D to build new OSG models and edit existing 
models. Have a look at www.remograph.com where you can download a fully 
functional evaluation version of Remo 3D.


Regards,
Andreas


On 2012-09-14 08:20, Theuns Heydenrych wrote:

Hi,
How do you build new osg models?
And how do you edit the existing models?

Thank you!

Cheers,
Theuns

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





___
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] Lines being culled

[Andreas Ekstrand]

Hi Robert,

Sure, here is the animation path. I zoom in and out a couple of times in 
the end of the path to show where it disappears. I wonder if it might be 
related to my ATI graphics card and its drivers...well, let's see if you 
can reproduce it first.


/Andreas



On 2012-09-04 16:38, Robert Osfield wrote:

Hi Andreas,

I tried to recreate the problem with your model but haven't seen it
yet.  Could you record a camera path that demonstrates the issue and
then post this so that we can test exactly the same thing as you.  In
osgviewer you can press 'z' to start recording the camera path then
'Z' to finish and replay the path.  The file saved will be
saved_animation.path, and to replace this in osgviewer you'd use:

  osgviewer result2.osg -p saved_animation.path

Robert.

On 4 September 2012 15:30, Andreas Ekstrand
andreas.ekstr...@remograph.com wrote:

Hi,

I have a problem with lines being culled. Running osgviewer on the attached
osg file and zooming in on e.g. the top right corner of the geometry,
consisting of lines representing normals, will result in a sudden culling of
all the lines. I have tried disabling culling altogether, made sure backface
culling is off and all sorts of precautions regarding depth test etc. (see
the state set in the osg file) but I can't get it to stay in view when
zooming in.

What might be the cause of this? Has someone else experienced this? Can
someone reproduce the problem? I use OSG 3.0.1.

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



0.000696070968497482 2148.97998046875 -1419.13293457031 156.382507324219 
0.707106781186548 0 0 0.707106781186548
0.0699708689542101 2148.97998046875 -1419.13293457031 156.382507324219 
0.707106781186548 0 0 0.707106781186548
0.139919413865792 2148.97998046875 -1419.13293457031 156.382507324219 
0.707106781186548 0 0 0.707106781186548
0.199948398524417 2148.97998046875 -1419.13293457031 156.382507324219 
0.707106781186548 0 0 0.707106781186548
0.270015883007378 2147.92557089404 -1419.01785670261 176.286059630242 
0.703018200962319 8.26866960287859e-005 -0.000518097671577871 0.711171662718234
0.340036889565523 2145.62630033926 -1417.81958296193 223.621133729184 
0.693197721765575 0.00032767138869332 -0.00174209757726281 0.720745292226393
0.399983165476051 2139.68783059861 -1407.42989543114 356.827997543489 
0.664783110348327 0.000986130269286395 -0.00515699955770691 0.747017971067804
0.469952570558613 2136.12052832725 -1375.94880909789 539.855753714363 
0.623628049361039 0.00291741787136331 -0.00962974233510827 0.781656454451486
0.539956376624898 2137.95133471062 -1339.70648820578 673.846479995252 
0.591676193089214 0.00520059105325313 -0.012484252420843 0.806062267958031
0.599903018503338 2143.80523738044 -1284.79968371538 823.974014436394 
0.553669758548842 0.00840057258550974 -0.0153392365213396 0.832552663001954
0.649976944021548 2147.35798211914 -1258.23869081301 884.088460264419 
0.53768953663796 0.0098773571098232 -0.0163583689278756 0.842926333538466
0.719940859585432 2152.16792285005 -1225.3873611706 950.931880385933 
0.519335571988979 0.0116546432028997 -0.0173939204121277 0.854313867668897
0.789953448881602 2155.2109048953 -1213.88359891992 972.718130886722 
0.513203601722027 0.0125128895515685 -0.0174027541265714 0.857999204500458
0.850045745988992 2157.62227731718 -1206.58540685262 986.149904959701 
0.509382939612347 0.0131448986966753 -0.0172850708793774 0.860265923302111
0.900685823866963 2157.91668874775 -1204.73472914603 989.513711490872 
0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852
0.970117988054807 2157.91668874775 -1204.73472914603 989.513711490872 
0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852
1.04028794355311 2157.91668874775 -1204.73472914603 989.513711490872 
0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852
1.10022507026584 2157.91668874775 -1204.73472914603 989.513711490872 
0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852
1.17028267361518 2157.91668874775 -1204.73472914603 989.513711490872 
0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852
1.240051528282 2157.91668874775 -1204.73472914603 989.513711490872 
0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852
1.30008527052348 2157.91668874775 -1204.73472914603 989.513711490872 
0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852
1.35009076004216 2157.91668874775 -1204.73472914603 989.513711490872 
0.508423027740886 0.0132441929692083 -0.017332703289 0.86083110638852
1.40040915212554 2173.69867546522 -1202.07465143341 994.171151291092 
0.508423027740886

Re: [osg-users] Lines being culled

[Andreas Ekstrand]

Ah...I tried on a different computer and it works fine there. Could it 
be that freaking ATI card again...will try updated drivers


/Andreas


On 2012-09-04 16:43, Andreas Ekstrand wrote:

Hi Robert,

Sure, here is the animation path. I zoom in and out a couple of times 
in the end of the path to show where it disappears. I wonder if it 
might be related to my ATI graphics card and its drivers...well, let's 
see if you can reproduce it first.


/Andreas



On 2012-09-04 16:38, Robert Osfield wrote:

Hi Andreas,

I tried to recreate the problem with your model but haven't seen it
yet.  Could you record a camera path that demonstrates the issue and
then post this so that we can test exactly the same thing as you.  In
osgviewer you can press 'z' to start recording the camera path then
'Z' to finish and replay the path.  The file saved will be
saved_animation.path, and to replace this in osgviewer you'd use:

  osgviewer result2.osg -p saved_animation.path

Robert.

On 4 September 2012 15:30, Andreas Ekstrand
andreas.ekstr...@remograph.com  wrote:

Hi,

I have a problem with lines being culled. Running osgviewer on the attached
osg file and zooming in on e.g. the top right corner of the geometry,
consisting of lines representing normals, will result in a sudden culling of
all the lines. I have tried disabling culling altogether, made sure backface
culling is off and all sorts of precautions regarding depth test etc. (see
the state set in the osg file) but I can't get it to stay in view when
zooming in.

What might be the cause of this? Has someone else experienced this? Can
someone reproduce the problem? I use OSG 3.0.1.

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



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

Re: [osg-users] Lines being culled

[Andreas Ekstrand]

Hi Robert,

Thank you, that did the trick. The latest ATI drivers didn't work with 
display lists either. So it seems NVidia is still superior with OpenGL 
compared to ATI, as always...


Regards,
Andreas


On 2012-09-04 17:01, Robert Osfield wrote:

Hi Andreas,

On 4 September 2012 15:56, Andreas Ekstrand
andreas.ekstr...@remograph.com wrote:

Ah...I tried on a different computer and it works fine there. Could it be
that freaking ATI card again...will try updated drivers

I tried with your animation path and can't recreate the problem on my
Kubuntu 12.04/NVidia 560Ti system.

I would suspect a driver issue.  One thing you could try is disabling
the use of display lists in the results2.osg to see if that effects
things - you can do this by just setting the useDisplayList TRUE entry
in the .osg to FALSE.

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

Re: [osg-users] 3D Modeler for OpenScenegraph

[Andreas Ekstrand]

Hi Andrea,

Have a look at Remo 3D - an OpenSceneGraph-based and cost-effective 
alternative to Creator:

http://www.remograph.com/

Regards,
Andreas


On 2012-06-25 16:54, Andrea Martini wrote:

Hi,
so far, to display a 3D model with a hierarchy of nodes already included in the 
model (such as DOF, SWITCH, LOD, ...), I used Multigen Creator, with models in 
flt format. There is the possibility of having a 3D model (not Multigen 
creator) that contains this hierarchy? For example, if you want to model a 
mechanical arm with Multigen, you can put DOF nodes in place of the elbow and 
the wrist. Then, in OSG, you can read these nodes and move mecchanical arm and 
wrist. There is another 3D modeling software (no Multigen Creator) that allows 
me to read such information from the model,  without which software I should 
have to manually insert a DOF node in the tree scene?
Do you think Blender can do that?

Thank you!

Cheers,
Andrea

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





___
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] Community news: Remo 3D v2.2

[Andreas Ekstrand]

Hi all,

Just wanted to let you know that I recently added another community news 
item:

http://www.openscenegraph.org/projects/osg/blog/remo2_2_released

Once again, I'm trying to call for more frequent updating of the 
community news. I think it would be interesting for all to keep 
up-to-date with OSG-related projects and products out there, compiled 
into this convenient news list.


Regards,
Andreas

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

Re: [osg-users] OSG Model Editor?

[Andreas Ekstrand]

Hi Dennis,

Have a look at Remo 3D, an OSG-developed 3D modeling tool. Although its 
native format if OpenFlight, it supports OSG/IVE and a lot of other file 
formats for both import and export:


www.remograph.com

Regards,
Andreas


On 2012-01-24 12:49, Dennis Cappendijk wrote:

I could not get osgedit to function properly with updated libs and 3.0.1 osg, 
So I am still looking for a osg (visual) model editor.

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





___
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] 3D models used in OSG ?

[Andreas Ekstrand]

Hi Maia,

May I suggest that you take a look at Remo 3D, a 3D modeler with 
OpenSceneGraph support, available from www.remograph.com. There is a 30 
days fully functional evaluation license available.


Regards,
Andreas


On 2011-10-27 21:25, Maia Randria wrote:

Hi,

First, I am sorry if my questions seem naive, I am really a newbie in OSG/3D.

My question is about the 3D models used by both of you in OSG:
- do you create your own 3D models yourselves with OSG ?
- or with other software like Blender, 3DS Max, Maya ?
- or do you buy or export free ones. Creating such 3D models needs artistic 
abilites and a lot of time, that's why my questionning ?

The next question is about the exportation between 3DS max (or Blender, 
whatover 3D modeler) to OSG: when exporting, for example, an animated 3D models 
from these 3D modelers, does OSG preserve these animations/texturing ? Or, all 
are lost and need to be redefined with OSG ?

Thank you!

Cheers,
Maia

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





___
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] [3rdparty] Scene Graph Viewing App

[Andreas Ekstrand]

Hi Conan,

Another tool you could use is Remo 3D (www.remograph.com). It's 
commercial, but the free demo version works as a viewer and supports 
plenty of file formats and an intuitive tree view.


Regards,
Andreas


On 2011-09-13 07:27, Sergey Kurdakov wrote:

Hi Conan,

maybe following would be useful:

there are several old tools

http://osgedit.sourceforge.net/
http://sourceforge.net/projects/osgscenemaker/

 not sure how well they could serve, but from screenshots it looks like
 you may access the structure ( but you would need to compile these 
tools with your version of osg )


commercial app to view structure is 
http://www.simlab-soft.com/3d-products/simlab-composer-main.aspx

it supports OSG files.

Regards
Sergey




___
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] Rewriting of the osgt reader (was: Re: Infinite loop at osgt loading)

[Andreas Ekstrand]

Hi Wang,

I can confirm that your fix works, with the models in 
OpenSceneGraph-Data-3.0.0 and also with a couple of my own models. I use 
Windows 7 64 bit and VC++ 2008 Express.


Regards,
Andreas


On 2011-07-01 03:36, Wang Rui wrote:

Hi All,

A serious problem was found that some newly added .osgt models
(spaceship, lz and dumptruck) will cause infinite loop while reading.
I've studied into the source code and guessed the reason is that
istream under Windows doesn't handle unget() in an expected way. That
is, the reading buffer may be filled somehow so that unget() will fail
and thus mark the entire stream as 'bad'. The whole loading process
will then be locked and that's what we see currently. The problem can
be located in osgPlugins/osg/AsciiStreamOperator.h,
AsciiInputIterator::matchString() method.

I tried handling the stream in some other ways but couldn't work out a
good one that could put back characters stablely. To avoid opening
another can of worms, finally I decide to rewrite some of the osgt
reader and treat the string to be wrote back as a 'pre-read' string
that would be handled later before the stream. A quick test shows that
these models can be loaded successfully after the modification.

Could you please help test the .osgt reader under Windows and other
platforms to make sure it can work? It will be appreciated if there
are enough feedbacks and bug reports before I could submit the change
with security.

Thanks,

Wang Rui


___
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] osgSim::MultiSwitch in osgt

[Andreas Ekstrand]

Hi,

Another problem with osgSim and osgt: When converting the attached 
switch_test.flt to switch_test.osgt with osgconv and then trying it in 
osgviewer, I get the following warnings (even if it loads and shows):


AsciiInputIterator::readProperty(): Unmatched property }, expecting 
SwitchSet
AsciiInputIterator::readProperty(): Unmatched property {, expecting 
SwitchSet
AsciiInputIterator::readProperty(): Unmatched property FALSE, expecting 
SwitchSet
AsciiInputIterator::readProperty(): Unmatched property 3, expecting 
SwitchSet


I don't know if it's the writing or reading that's failing. Maybe it 
would be a good idea to write the line number in these warnings, if it's 
possible.


Regards,
Andreas



switch_test.flt
Description: Binary data
#Ascii Scene 
#Version 80 
#Generator OpenSceneGraph 3.0.0 

osg::Group {
  UniqueID 1 
  Name db 
  UserDataContainer TRUE {
osg::DefaultUserDataContainer {
  UniqueID 2 
}
  }
  Children 1 {
osgSim::MultiSwitch {
  UniqueID 3 
  Name sw1 
  Children 3 {
osg::Group {
  UniqueID 4 
  Name o1 
  UserDataContainer TRUE {
osg::DefaultUserDataContainer {
  UniqueID 5 
  UDC_UserData {
osgSim::ObjectRecordData {
  UniqueID 6 
  Data Flags 0 
  RelativePriority 0 
  Transparency 0 
  EffectID1 0 
  EffectID2 0 
  Significance 0 
}
  }
}
  }
  Children 1 {
osg::Geode {
  UniqueID 7 
  Name p1 
  DataVariance STATIC 
  StateSet TRUE {
osg::StateSet {
  UniqueID 8 
  DataVariance STATIC 
  ModeList 2 {
GL_CULL_FACE ON 
GL_LIGHTING OFF 
  }
  AttributeList 1 {
osg::CullFace {
  UniqueID 9 
}
Value OFF 
  }
}
  }
  Drawables 1 {
osg::Geometry {
  UniqueID 10 
  DataVariance STATIC 
  PrimitiveSetList 1 {
DrawArrays GL_QUADS 0 4 

  }
  VertexData {
Array TRUE ArrayID 1 Vec3fArray 4 {
  -3 0 -1 
  -1 0 -1 
  -1 0 1 
  -3 0 1 
}
Indices FALSE 
Binding BIND_PER_VERTEX 
Normalize 0 
  }
  ColorData {
Array TRUE ArrayID 2 Vec4fArray 1 {
  1 0 0 1 
}
Indices FALSE 
Binding BIND_OVERALL 
Normalize 0 
  }
}
  }
}
  }
}
osg::Group {
  UniqueID 11 
  Name o2 
  UserDataContainer TRUE {
osg::DefaultUserDataContainer {
  UniqueID 12 
  UDC_UserData {
osgSim::ObjectRecordData {
  UniqueID 13 
  Data Flags 0 
  RelativePriority 0 
  Transparency 0 
  EffectID1 0 
  EffectID2 0 
  Significance 0 
}
  }
}
  }
  Children 1 {
osg::Geode {
  UniqueID 14 
  Name p2 
  DataVariance STATIC 
  StateSet TRUE {
osg::StateSet {
  UniqueID 8 
}
  }
  Drawables 1 {
osg::Geometry {
  UniqueID 15 
  DataVariance STATIC 
  PrimitiveSetList 1 {
DrawArrays GL_QUADS 0 4 

  }
  VertexData {
Array TRUE ArrayID 3 Vec3fArray 4 {
  -1 0 -1 
  1 0 -1 
  1 0 1 
  -1 0 1 
}
Indices FALSE 
Binding BIND_PER_VERTEX 
Normalize 0 
  }
  ColorData {
Array TRUE ArrayID 4 Vec4fArray 1 {
  1 1 0 1 
}
Indices FALSE 
Binding BIND_OVERALL 
Normalize 0 
  }
}
  }
}
  }
}
osg::Group {
  UniqueID 16 
  Name o3 
  UserDataContainer TRUE {

Re: [osg-users] osgSim::MultiSwitch in osgt

[Andreas Ekstrand]

Great, Wang. Thanks for looking into these issues so quickly. Much 
appreciated.


Regards,
Andreas


On 2011-07-01 08:45, Wang Rui wrote:

Hi Andreas,

Ahhh... I'll try to fix it this weekend. It is just another slip of the pen.

Wang Rui


2011/7/1 Andreas Ekstrandandreas.ekstr...@remograph.com:

Hi,

Another problem with osgSim and osgt: When converting the attached
switch_test.flt to switch_test.osgt with osgconv and then trying it in
osgviewer, I get the following warnings (even if it loads and shows):

AsciiInputIterator::readProperty(): Unmatched property }, expecting
SwitchSet
AsciiInputIterator::readProperty(): Unmatched property {, expecting
SwitchSet
AsciiInputIterator::readProperty(): Unmatched property FALSE, expecting
SwitchSet
AsciiInputIterator::readProperty(): Unmatched property 3, expecting
SwitchSet

I don't know if it's the writing or reading that's failing. Maybe it would
be a good idea to write the line number in these warnings, if it's possible.

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] Lightpoints in osgt/osgb/osgx

[Andreas Ekstrand]

Hi Wang,

Thanks for the quick fix, it works like a charm! I see you're back 
online, so will you submit it?


Regards,
Andreas


On 2011-06-29 17:35, Wang Rui wrote:

Hi Andreas,

I can confirm this is a bug in the osgSim::LightPointNode serializer
and have quickly repaired it as attached. As it is already late in
China and I'm really sleepy now :-) could you please help me test it
again and if it's usable this time,could you please help me submit it
to the osg-submissions?

Cheers,

Wang Rui


2011/6/29 Andreas Ekstrandandreas.ekstr...@remograph.com:

Hi,

I'm having problems with osgSim::LightPoint in the new osgt/osgb/osgx
formats. After converting the attached lightpoint_test.flt to these formats
with osgconv, loading them in osgviewer causes warnings and no data loaded
for osgt/osgb and incomplete geometry for osgx (only the lightpoint, not the
polygon).

Looking at the osgt file created (also attached), the Sector and
BlinkSequence objects are empty, which seems to cause the error. I don't
know if it fails in the osgt writing or reading of osgt, or maybe in the
reading of flt. Is a LightPoint without Sector or BlinkSequence considered
non-valid? Is it okay to expect these in the osgt reading?

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

[osg-users] Infinite loop at osgt loading

[Andreas Ekstrand]

Hi,

With OpenSceneGraph-3.0.0, loading 
OpenSceneGraph-Data-3.0.0/spaceship.osgt in osgviewer hangs in an 
infinite loop in AsciiInputIterator::advanceToCurrentEndBracket. I 
haven't been able to find the cause for this, maybe someone more 
knowledgeable in these new formats understands what's going on? If I'm 
not the only one experiencing this?


Regards,
Andreas

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

Re: [osg-users] Infinite loop at osgt loading

[Andreas Ekstrand]

Hi J-S,

Thanks for the confirmation. I'm also on Windows 7 64 bit, VC++ 2008 
Express. It hangs in both x86 and x64 builds.


It seems readString( passString ) always returns the empty string for 
the osg::Geometry with UniqueID 8 and that the readObjectFields for this 
geometry didn't manage to read any primitive sets into the geometry. I 
guess bailing out nicely somehow from the loop in 
advanceToCurrentEndBracket would be preferable, as finding the cause for 
the failed reading of the geometry of course. All this complex enough to 
prevent me from fixing it in a jiffy though...


Regards,
Andreas


On 2011-06-29 16:04, Jean-Sébastien Guay wrote:

Hi Andreas,


With OpenSceneGraph-3.0.0, loading
OpenSceneGraph-Data-3.0.0/spaceship.osgt in osgviewer hangs in an
infinite loop in AsciiInputIterator::advanceToCurrentEndBracket. I
haven't been able to find the cause for this, maybe someone more
knowledgeable in these new formats understands what's going on? If I'm
not the only one experiencing this?


I can confirm. Windows 7 64 bit, VC++ 2008 x64 build.

What platform/compiler are you using?

I can't look into it right now, just wanted to confirm I'm seeing this 
also.


J-S

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

[osg-users] Lightpoints in osgt/osgb/osgx

[Andreas Ekstrand]

Hi,

I'm having problems with osgSim::LightPoint in the new osgt/osgb/osgx 
formats. After converting the attached lightpoint_test.flt to these 
formats with osgconv, loading them in osgviewer causes warnings and no 
data loaded for osgt/osgb and incomplete geometry for osgx (only the 
lightpoint, not the polygon).


Looking at the osgt file created (also attached), the Sector and 
BlinkSequence objects are empty, which seems to cause the error. I don't 
know if it fails in the osgt writing or reading of osgt, or maybe in the 
reading of flt. Is a LightPoint without Sector or BlinkSequence 
considered non-valid? Is it okay to expect these in the osgt reading?


Regards,
Andreas



lightpoint_test.flt
Description: Binary data
#Ascii Scene 
#Version 80 
#Generator OpenSceneGraph 3.0.0 

osg::Group {
  UniqueID 1 
  Name db 
  UserDataContainer TRUE {
osg::DefaultUserDataContainer {
  UniqueID 2 
}
  }
  Children 1 {
osg::Group {
  UniqueID 3 
  Name g1 
  Children 2 {
osgSim::LightPointNode {
  UniqueID 4 
  Name lp1 
  StateSet TRUE {
osg::StateSet {
  UniqueID 5 
  DataVariance STATIC 
  RenderBinMode USE_RENDERBIN_DETAILS 
  BinNumber 20 
  BinName DepthSortedBin 
}
  }
  LightPointList 1 {
LightPoint {
  Position 0 0 0.1 
  Color 1 0 0 1 
  Attributes TRUE 1 1 2 
  Sector BlinkSequence }
  }
  MinPixelSize 2 
  MaxPixelSize 8 
}
osg::Geode {
  UniqueID 6 
  Name p1 
  DataVariance STATIC 
  StateSet TRUE {
osg::StateSet {
  UniqueID 7 
  DataVariance STATIC 
  ModeList 2 {
GL_CULL_FACE ON 
GL_LIGHTING OFF 
  }
  AttributeList 1 {
osg::CullFace {
  UniqueID 8 
}
Value OFF 
  }
}
  }
  Drawables 1 {
osg::Geometry {
  UniqueID 9 
  DataVariance STATIC 
  PrimitiveSetList 1 {
DrawArrays GL_QUADS 0 4 

  }
  VertexData {
Array TRUE ArrayID 1 Vec3fArray 4 {
  -1 -1 0 
  1 -1 0 
  1 1 0 
  -1 1 0 
}
Indices FALSE 
Binding BIND_PER_VERTEX 
Normalize 0 
  }
  ColorData {
Array TRUE ArrayID 2 Vec4fArray 1 {
  1 1 1 1 
}
Indices FALSE 
Binding BIND_OVERALL 
Normalize 0 
  }
}
  }
}
  }
}
  }
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Community news: Remo 3D v2.1

[Andreas Ekstrand]

Hi all,

Just wanted to let you know that I recently added the first community 
news item since 2009. :-)

http://www.openscenegraph.org/projects/osg/blog/Remo3Dv2.1

It would be nice if that section was more active, always fun to know 
what happens with OSG-related projects and products.


Regards,
Andreas

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

Re: [osg-users] flt file not working

[Andreas Ekstrand]

Hi Peter,

I think your FLT file is invalid. There doesn't seem to be any push 
record between the header node with its ancillary records and the 
following group node. Where does test.flt come from?


Regards,
Andreas Ekstrand


On 2011-03-25 11:45, Peter Wraae Marino wrote:

Hej osgUsers,

I have attached an flt file which will not load with osgviewer.
I have also tried to convert it to a .osg file and it becomes:
Group {
  name db
  nodeMask 0x
  cullingActive TRUE
}

which is pretty much empty?

we are using osg version 2.8.3 on windows 7
the flt file loads fine in a terravista buildt in viewer and polytrans.

any ideas why it doesn't work with osgviewer?

regards,
Peter

--
Bellinge Gymnasterne: http://www.bellingegymnasterne.dk
Power Tumbling: http://www.powertumbling.dk
OSG-Help: http://code.google.com/p/sigmaosg
Personal Site: http://www.marino.dk


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



--
*__*
*Andreas Ekstrand*
*CEO / Co-founder*
Phone: +46 708 490697
Fax: +46 13 9913093
andreas.ekstr...@remograph.com mailto:andreas.ekstr...@remograph.com

*Remograph AB*
Norrbergavägen 58
SE-590 54 Sturefors
SWEDEN
www.remograph.com http://www.remograph.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [forum] HOW TO ADD CUSTOM COLOURS TO THE MODEL

[Andreas Ekstrand]

Hi Nagore,

An alternative is to use Remo 3D for this. It supports STL (binary .sta 
and ASCII .stl) and many of OpenSceneGraph's supported formats for 
import and export. Remo 3D is available at www.remograph.com.


Regards,
Andreas


On 2011-03-08 11:45, Alberto Luaces wrote:

Nagore Barrena writes:


Hi,

I'm working in Windows XP with Osg-2.8.2. I use Catia to generate my 3d models. 
The only possibility to save the model in Catia and then to load it right in 
osg is to save the model in .stl extension. But
when I save the model using this extension the model loses the colour, 
transforming into a grey model.

I load the 3d model using osgDB::readNodeFile() method:
modelNode = osgDB::readNodeFile(model.stl);

Do you know how I can add custom colours to the model using OSG methods?


You can assign a StateSet in the code with a material definition which
overrides the colour of the model.

Or you can import the file in Blender, fine tune the material definition
for the object, save it into OBJ format and open it into OSG.



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

Re: [osg-users] Getting height data of a terrain(flt file)

[Andreas Ekstrand]

Hi Mukund,

I just meant that you could implement a spatial traverse over the
terrain bounding box with equal steps in X and Y, intersect vertically
with the terrain and put the resulting terrain heights in an image which
you can write to disk with one of the OSG image plugins implementing
writeImage. If an elevation raster on disk is what you want, that is.

Regards,
Andreas


On 2 mar 2011 14:37 Mukund Keshav osgfo...@tevs.eu
osgfo...@tevs.eu wrote:

 Thanks Chris, Andreas, Gordon.
 
 @Andreas.
 
 
  However, if you want to extract a regular terrain height raster from
  an OpenFlight database, I would say the best solution is to write an
  OSG application that simply intersects vertically with the terrain
  at equal distances and puts the result in a raster that you write to
  disk
 
 
 The method you suggested sounded interesting. Could you please
 elaborate a little more? i understood till the part where i can make
 the terrain intersect with say equidistant lines. But after that, i
 did not get you.
 
 Could you please explain?
 
 
 
 Thanks for the support,
 Mukund
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=37250#37250
 
 
 
 
 
 ___
 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] Getting height data of a terrain(flt file)

[Andreas Ekstrand]

Hi Mukund,

OpenFlight is quite complicated yes, but actually more well documented
nowadays. However, if you want to extract a regular terrain height
raster from an OpenFlight database, I would say the best solution is to
write an OSG application that simply intersects vertically with the
terrain at equal distances and puts the result in a raster that you
write to disk. Also, this would of course be a general file
format-agnostic solution.

Regards,
Andreas


On 2 mar 2011 04:53 Chris 'Xenon' Hanson xe...@alphapixel.com
xe...@alphapixel.com wrote:

 On 3/1/2011 7:54 PM, Mukund Keshav wrote:
  Hi Robert,
  Thanks for the reply. Could you please tell where i can find the
  exact file format for flt files?
 
 FLT isn't really an OSG format, it's a MultiGen format. Documentation
 on it is very poor
 and sparse. I wouldn't pursue this unless you REALLY need to look into
 the format. Grown
 men have been known to be reduced to tears trying to understand FLT.
 
  Thanks,
  Mukund___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Draw Order/Culling with OpenFlight and Transparency

[Andreas Ekstrand]

Hi Murray,

I agree with Gordon, this seems to be a classical transparent sorting 
issue. You could try using the preserveFace or preserveObject 
keywords in the option string to the OpenFlight loader, in order to sort 
them separately and not merging into fewer drawables. This may be bad 
for performance if you have many helicopters in your scene, but it might 
solve your sorting issue.


Regards,
Andreas

*__*
*Andreas Ekstrand*
*CEO / Co-founder*
Phone: +46 708 490697
Fax: +46 13 9913093
andreas.ekstr...@remograph.com mailto:andreas.ekstr...@remograph.com

*Remograph AB*
Norrbergavägen 58
SE-590 54 Sturefors
SWEDEN
www.remograph.com http://www.remograph.com/


On 2011-02-24 15:40, Tomlinson, Gordon wrote:


Hi Murray

In my experience this looks like a classic transparency sorting 
issue/problem when you have objects that have transparency and their 
objects bounding volumes intersect,( I would also say this has little 
to do with you using open flight)


This happens because for efficiency scene graphs sort transparent 
object at a geode level and not at a polygonal level, you find this 
has been discussed many time in many places


If you look at you model its likely that you Rotors are in one object 
 and then the windows/glass in another ( you might have more), is you 
the think of their 2 bounding spheres they will be intersecting, so as 
you view changes then how that are possibly sorted will change hence 
you get the punch through effect you see.


One way to try to minimize this is to try and ensure when you create a 
model you don't create overlap transparency that overlap, this can be 
challenging to do depending on what you are modeling


(you also have to watch for optimizers in Scenegraphs that try to 
chunk like materials and texturing in to one group  as this can 
artificially  introduce overlaps)


You can also try to use a an opaque texture to represent windows/port 
holes (do you really need them to be transparent?) to help.


You can create you own render bin that sorts at the triangle level for 
these models


*/Gordon Tomlinson/*

*/3D Technology/**//*

*/System Engineering Consultant/*

*/Overwatch®/*

*/An Operating Unit of Textron Systems/**//*

__
WARNING: Documents that can be viewed, printed or retrieved from this 
E-Mail may contain technical data whose export is restricted by the 
Arms Export Control Act (Title 22, U.S.C., Sec 2751, et seq,) or the 
Export Administration Act of 1979, as amended, Title 50, U.S.C., App. 
2401 et seq. and which may not be exported, released or disclosed to 
non-U.S. persons (i.e. persons who are not U.S. citizens or lawful 
permanent residents [green card holders]) inside or outside the 
United States, without first obtaining an export license.  Violations 
of these export laws are subject to severe civil, criminal and 
administrative penalties.


*From:*osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] *On Behalf Of 
*Murray G. Gamble

*Sent:* Wednesday, February 23, 2011 2:37 PM
*To:* OpenSceneGraph Users
*Subject:* Re: [osg-users] Draw Order/Culling with OpenFlight and 
Transparency


Thanks for the suggestion, Chuck.

I've tried this, and do not observe any appreciable improvement in 
rendering.  I should point out that while the images I provided 
highlight the main rotor disc as the offending geometry, there are 
numerous other geometry elements (e.g., windows) that cause similar 
issues when viewed from various angles.


I've stepped through the OpenFlight loader in debug mode and have 
observed that the rotors and windows are both being caught by the 
tests therein for translucent images and transparent materials, 
respectively.  These tests result in the state sets being set as 
you've suggested, so it appears that OpenFlight loader is treating 
these nodes correctly.


Any other ideas?

Murray

On 2011-02-23, at 1:57 PM, Chuck Seberino wrote:



Murray,

Your rotor is being placed in the Opaque render bin, which is causing 
all of the geometry behind it to be culled out.  You need to make sure 
it is in the transparent bin.  You should add these to the stateSet of 
the rotors:


 stateSet-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
 stateSet-setMode(GL_BLEND, osg::StateAttribute::ON);

HTH,
Chuck

On Feb 23, 2011, at 10:53 AM, Murray G. Gamble wrote:


Hi All,

We have an OpenFlight model of a helicopter that exhibits some
undesirable rendering behaviour in OSG.  Specifically, various
parts of the helicopter geometry are being culled and/or rendered
in the wrong order.  We do not observe this behaviour when
rendering the same model using Vega Prime.  I've attached a couple
of screen captures that exemplify the issues.

Can users with similar experiences provide any suggestions as to
how to avoid these rendering artifacts? Does the model

Re: [osg-users] Creating Image from Openflight file

[Andreas Ekstrand]

 Hi Geoff,

Could you provide an example FLT file where the problem is shown? It 
would greatly improve our ability to help you.


Regards,
Andreas


On 2010-10-05 21:57, Geoff Rhodes wrote:

Hi,

In looking into this a little bit more, it appears that it is not picking up a 
lot of the externally referenced textures and flt files. When i load the main 
FLT file, it will load in OSGViewer and show properly, but when I load it with 
my program, it seems to only load the the last referenced FLT file.

The structure of the file is this:

Main
   |
   +--+---+---+--+
  #1  #2  #3   #4  #5

Each number is translated to it's proper position in the main file


Another thing I noticed is that the FLT files are all built with the same 
origin, Meaning #1 through #5 are all built at origin 100,100 for X,Y. Not sure 
if this has anything to do with my issue, where they might be getting 
overlapped by each subsequent one when being built.

Thank you!

Cheers,
Geoff

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





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




--
__
Andreas Ekstrand
Remograph
Norrbergavägen 58
SE-590 54 Sturefors
SWEDEN
Web: www.remograph.com
E-mail: andreas.ekstr...@remograph.com
Phone: +46 708 490697

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

[osg-users] Contractors/Applications/Users pages

[Andreas Ekstrand]

 Hi,

How do I add our company to the Contractors, Applications and Users 
pages? The http://www.openscenegraph.org/projects/osg/register link just 
gives me No handler matched request to /register. Should I provide our 
information to someone else editing the Wiki?


Regards,
Andreas Ekstrand
Remograph

--
__
Andreas Ekstrand
Remograph
Norrbergavägen 58
SE-590 54 Sturefors
SWEDEN
Web: www.remograph.com
E-mail: andreas.ekstr...@remograph.com
Phone: +46 708 490697

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

Re: [osg-users] Texture problem on 64-bit PC

[Andreas Ekstrand]

Hi,

I have similar problems with an ATI Radeon HD 5850 in Windows 7 64bit. 
Textures are corrupted, it seems like the MIP levels are mixed together 
somehow, so that different textures are shown and blended together 
depending on the viewing distance and angle. I have tried different 
versions of the Catalyst drivers but to no avail. The phenomenon doesn't 
appear with all models but it feels like it's an ATI driver issue 
anyway, triggered by something special in the failing models, but I 
haven't figured out what just yet.


Does anyone else have the same problem or know how to solve it?

Regards,
Andreas


On 2010-07-08 17:48, Gordon Tomlinson wrote:

I would have to disagree and say that it is likely to be a hardware\driver
issue

I have been running OSG on 64 with Nvidia for 3 years and had no issues

There have bee quite a few posts recently about continued issues with ATI
catalyst drivers and their broken Opengl Support, the suggestions from the
post is to use catalyst  10.4 drivers



__
Gordon Tomlinson

gor...@gordontomlinson.com IM: gordon3db...@3dscenegraph.com
www.vis-sim.com
www.gordontomlinson.com
www.PhotographyByGordon.com

__

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Werner
Stoop
Sent: Thursday, July 08, 2010 4:29 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Texture problem on 64-bit PC

Hi,

I recently received a new 64-bit machine at work. When I now use osgviewer
to the textures on some of our models seem smeared where they displayed
correctly on my older 32-bit PC.

Other models do display correctly, so I don't think it's a hardware issue.

Our models are in the form of IVE files, and some of them are generated by
(an older version of) Virtual Planet Builder.

For what it's worth, my PC runs Fedora 12 and has an ATI Radeon HD 3450
graphics card. I also had Fedora 12 on my previous PC, but it had a NVidia
card.

I would post an image, but I'm a newbie, so I'm not allowed to post URLs

Has anyone had similar problems? what causes it? How can I resolve it or fix
the models?

Thank you!
Werner[/i]

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





___
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] 3d Model Editing

[Andreas Ekstrand]

Hi John,

Have a look at Remo 3D (www.remograph.com) which supports import and 
export of most of the file formats in OpenSceneGraph.


/Andreas


On 2010-03-27 16:58, John Galt wrote:

Hi,

I need separate models of a man's body and head. Can you suggest where I can 
find them? Any of these file formats will do: 3dc, 3ds, flt, geo, iv, ive, lwo, 
md2, obj, osg.

Also, does anyone know how to edit an osg model. For instance in the example 
cow.osg, how do I edit it so that only its head is present and the body is 
deleted?

Thank you!

Cheers,
John

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





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

   



--
__
Andreas Ekstrand
Remograph
Norrbergavägen 58
SE-590 54 Sturefors
SWEDEN
Web: www.remograph.com
E-mail: andreas.ekstr...@remograph.com
Phone: +46 708 490 697

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

Re: [osg-users] [osgPlugins] OpenFlight - Palette Records prevent using of ReaderWriter Callback

[Andreas Ekstrand]

Hi Alex,

No it's not free but it's at least much cheaper than Creator. :-)

/Andreas


On 3 mar 2010 11:50 Alexandre Amalric alex.pix...@gmail.com wrote:

 Hi Andreas,
 
 
 
 
 
 Have a look at Remo 3D (http://www.remograph.com) which supports
 removing unused textures in OpenFlight files very easily through
 scripting. A simple Lua script would let you remove unused textures in
 a large number of files.
 
 
 
 
 I just tested Remo3d scripting in Lua, it's very usefull.
 Unfortunately it isn't free, if we want to save models with more than
 100 polygons we have to purchase the product.
 
 
 
 
 Hi Jason,
 
 
 
 
 I think what Paul meant is that you'd have to modify the plugin to
 only load the texture when it encounters a reference to it in the
 traversal of the main document. Currently, it loads the texture
 palette at the beginning. You'd have to modify it in some way to delay
 the actual texture load until a primary record references it.
 
 
 
 
 I think about this solution since the begining but I'm not sure that
 those modifications won't bring errors when using the plugin in a
 normal way. Maybe that the original author from this plugin can tell
 me if the texture palette record has to be read or not, so we may
 decide to skip it.
 
 
 
 
 
 
 
 2010/3/3 Trajce (Nick) Nikolov nikolov.tra...@gmail.com
 
 
 
  I know this command in Creator but we want to automatize the process
  because we work on hundred of files like this.
  
  
  
  Building a creator API is maybe a solution but I don't know if there
  is a function to remove unused texture on a Openflight model. I will
  look for this.
  
  
  
  
  
  
  
  you dont need any api for this. simply download the openflight spec,
  read the palette record, parse the face record and count the used
  textures, and clone all the records into new file. Very simple
  
  
  -Nick
  
  
  
  
  
  
  
  
  
  On Tue, Mar 2, 2010 at 10:07 AM, Alexandre Amalric
  alex.pix...@gmail.com wrote:
  
  
  
   Hi Paul,
   
   
   
   
   
   You'd need to modify the OpenFlight plugin to support this.
   
   
   
   
   I tried to do this but in the TexturePalette::readRecord function
   there is no way to know if a texture is used or not by the model.
   The only parameters we get from a texture (RecordInputStream) are
   :
   
   - the filename
   
   - the index
   
   - X
   
   - Y
   
   
   
   
   hi Tomlinsom,
   
   
   
   
   Simplest way would be to open up the file in Creator and use the
   remove
   unused textures command
   
   
   
   
   I know this command in Creator but we want to automatize the
   process because we work on hundred of files like this.
   
   
   
   Building a creator API is maybe a solution but I don't know if
   there is a function to remove unused texture on a Openflight
   model. I will look for this.
   
   
   
   
   
   Kind regards,
   
   
   
   
   
   2010/3/2 Tomlinson, Gordon gtomlin...@overwatch.textron.com
   
   
   
Simplest way would be to open up the file in Creator and use the
remove
unused textures command




You could also write a simple Creator API app to do this on a
list of

flight files




Another option would be to load the file in to OSG and save out
as OSG

or IVE file again you could write a simple script to do this for
many

files







Gordon Tomlinson

Product Manager 3d Technology  Project Wyvern



Overwatch(r)



An Operating Unit of Textron Systems






-Original Message-
From: osg-users-boun...@lists.openscenegraph.org




[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf
Of Paul
Martz

Sent: Monday, March 01, 2010 10:29 AM

To: OpenSceneGraph Users




Subject: Re: [osg-users] [osgPlugins] OpenFlight - Palette
Records
prevent using of ReaderWriter Callback




Alexandre Amalric wrote:

 Hi osg-users,



 I have a question concerning the palette texture record. When

 converting a flt model which texture palette contains useless
 texture,




 they are even read. Is there a way to read only used texture.
 Let's

 say I have a simple model file using 1 texture but my texture
 palette

 in corresponding openflight model contains 100 textures, so
 99% are

 useless but the plugin read them.



 I know that it is a special case, but when working on
 Openflight

 models with Multigen Paradigm it happens a lot.



 Any suggestion ?




You'd need to modify the OpenFlight plugin to support this.

-Paul




___

osg-users mailing list

Re: [osg-users] [osgPlugins] OpenFlight - Palette Records prevent using of ReaderWriter Callback

[Andreas Ekstrand]

Hi Alex,

Have a look at Remo 3D (www.remograph.com) which supports removing 
unused textures in OpenFlight files very easily through scripting. A 
simple Lua script would let you remove unused textures in a large number 
of files.


/Andreas


On 2010-03-02 09:07, Alexandre Amalric wrote:

Hi Paul,

/You'd need to modify the OpenFlight plugin to support this./

I tried to do this but in the TexturePalette::readRecord function 
there is no way to know if a texture is used or not by the model. The 
only parameters we get from a texture (RecordInputStream) are :

- the filename
- the index
- X
- Y

hi Tomlinsom,

Simplest way would be to open up the file in Creator and use the remove
unused textures command

I know this command in Creator but we want to automatize the process 
because we work on hundred of files like this.


Building a creator API is maybe a solution but I don't know if there 
is a function to remove unused texture on a Openflight model. I will 
look for this.


Kind regards,

2010/3/2 Tomlinson, Gordon gtomlin...@overwatch.textron.com 
mailto:gtomlin...@overwatch.textron.com


Simplest way would be to open up the file in Creator and  use the
remove
unused textures command

You could also write a simple Creator API app to do this on a list of
flight files

Another option would be to load the file in to OSG and save out as
 OSG
or IVE file again you could write a simple script to do this for many
files


Gordon Tomlinson
Product Manager 3d Technology  Project Wyvern
Overwatch(r)
An Operating Unit of Textron Systems

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
mailto:osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org
mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul
Martz
Sent: Monday, March 01, 2010 10:29 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] [osgPlugins] OpenFlight - Palette Records
prevent using of ReaderWriter Callback

Alexandre Amalric wrote:
 Hi osg-users,

 I have a question concerning the palette texture record. When
 converting a flt model which texture palette contains useless
texture,

 they are even read. Is there a way to read only used texture.  Let's
 say I have a simple model file using 1 texture but my texture
palette
 in corresponding openflight model contains 100 textures, so 99% are
 useless but the plugin read them.

 I know that it is a special case, but when working on Openflight
 models with Multigen Paradigm it happens a lot.

 Any suggestion ?

You'd need to modify the OpenFlight plugin to support this.
   -Paul

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

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or%0Ag
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




--
Alexandre AMALRIC   Ingénieur RD
===
PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
http://www.pixxim.fr


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



--
__
Andreas Ekstrand
Remograph
Norrbergavägen 58
SE-590 54 Sturefors
SWEDEN
Web: www.remograph.com
E-mail: andreas.ekstr...@remograph.com
Phone: +46 708 490 697

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

Re: [osg-users] Edit mesh

[Andreas Ekstrand]

Hi Luis,

Have a look at Remo 3D, an affordable 3D modeling tool with support for 
OSG/IVE import/export:

www.remograph.com

/Andreas


Luis Agero wrote:

Hi Jason,

Yes, I know it is something out of OSG. But that would be interesting for my 
project not to use another software.

Luis

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





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

  



--
__
Andreas Ekstrand
Remograph
Norrbergavägen 58
SE-590 54 Sturefors
SWEDEN
Web: www.remograph.com
E-mail: andreas.ekstr...@remograph.com
Phone: +46 708 490 697

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

[osg-users] Announcing Remo 3D v1.4

[Andreas Ekstrand]

Hi,

A news item has been added to the wiki on the OSG website. Here is the
complete press release:

Remo 3D v1.4: New reduction tool, shaders, texture mappings and more!

Linköping, 12th December, 2007

Remograph today announced the release of Remo 3D version 1.4. Remo 3D is
an effective tool for creating and modifying 3D models intended for
realtime visualization. The primary file format is OpenFlight®. Remo 3D
is currently available for Microsoft® Windows® XP/2000 and Linux.

Remo 3D v1.4 contains a number of improvements over v1.3, including a
new tool for geometry simplification, new palettes for texture mappings,
shaders and light points, as well as support for exporting to the OBJ
file format. The full list of new features and improvements can be found
in the release notes on our website: http://www.remograph.com/


About Remograph:

Remograph provides products and services for the 3D modeling, computer
graphics and visual simulation industries. Our ambition is to develop
advanced and cost-effective solutions for end-users and developers of
e.g. visual simulation systems, visual databases or virtual reality
applications. Remograph is situated in Linköping, Sweden.

All trademarks referenced are properties of their respective owners.

For more information, visit our website at:
http://www.remograph.com/
or contact Remograph at:
[EMAIL PROTECTED]


-- 
__
Andreas Ekstrand
Remograph
Norrbergavägen 58
SE-590 54 Sturefors
SWEDEN
Website: http://www.remograph.com/
E-mail: [EMAIL PROTECTED]



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

Re: [osg-users] Creator vs 3D Studo Max

[andreas . ekstrand]

Hi,

An alternative to Creator is Remo 3D, available from www.remograph.com.

Regards
/Andreas


 Hi,

 I've a flight simulator project running on OSG 2.2 whereby we need to
 model a geo-specific airport.

 We will need features like creating the airport lighting system,
 geo-specific buildings, multiple LODs.

 We are considering whether to use Multigen Creator or 3D Studio Max to do
 the job, any advice? Thanks a lot


 ___
 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] Tree Creation Workflow

[Andreas Ekstrand]

Hi Nick,

Definitely OpenFlight, I think you'll find the best billboard support 
there. You can use Remo 3D to create trees and export them directly to 
IVE. You can even use the demo version for this (www.remograph.com).

/Andreas


Nick Prudent wrote:

For those who deal with terrain in OSG, what tool do you use to create trees 
as textured transparent billboard to be loaded by OSG? I'm just wondering 
what's the best native format for creating the trees. 

Examples:

FLT -- OSG -- IVE
or
3DS -- OSG -- IVE
or
VRML -- OSG -- IVE
...


Thanks,

- Nick -



_
Invite your mail contacts to join your friends list with Windows Live Spaces. 
It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


  



-- 
__
Andreas Ekstrand
Remograph
Norrbergavägen 58
SE-590 54 Sturefors
SWEDEN
Website: http://www.remograph.com/
E-mail: [EMAIL PROTECTED]

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

Re: [osg-users] Lightpoints on a string

[Andreas Ekstrand]

Hi Tim,

To support light point strings, the OpenFlight reader would have to 
implement the use of Replicate records. The class Replicate is defined 
in AncillaryRecords.cpp but doesn't seem to be used anywhere else.

/Andreas


[EMAIL PROTECTED] wrote:

Hi all,

in OpenFlight you can create a string of lightpoints by defining a
start- and endpoint and the count of lightpoints in-between. 

Did anybody manage to visualize this in OSG? I always get only one
lightpoint :-(


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

  



-- 
__
Andreas Ekstrand
Remograph
Norrbergavägen 58
SE-590 54 Sturefors
SWEDEN
Website: http://www.remograph.com/
E-mail: [EMAIL PROTECTED]

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