Re: [osg-users] [Build error] GL_SEPARATE_ATTRIBS not declared
2015-01-23 20:21 GMT+03:00 Mattias Helsing helsin...@gmail.com: Hi, I have been seeing these errors for a while when building OSG using an old android NDK. I don't use it but just tried to build OSG using a new Toolchain file provided a few months ago. I discarded it thinking it was due to me using an old NDK, but if anyone is interested i post nightly builds once in a while to: http://cdash.openscenegraph.org Matters maybe you know Ray Donnelly he works on Android NDK some time ago. We work with him on MSYS2 project now. I'm fix building OSG using next patch for including extra GL header: --- OpenSceneGraph/CMakeLists.txt.orig 2015-01-25 14:09:28.10540 +0300 +++ OpenSceneGraph/CMakeLists.txt 2015-01-25 14:09:37.49660 +0300 @@ -508,7 +508,7 @@ SET(OPENGL_HEADER2 CACHE STRING #include line for additional OpenGL Headers if required) ELSE() SET(OPENGL_HEADER1 #include GL/gl.h CACHE STRING #include line for OpenGL Header) -SET(OPENGL_HEADER2 CACHE STRING #include line for additional OpenGL Headers if required) +SET(OPENGL_HEADER2 #include GL/glext.h CACHE STRING #include line for additional OpenGL Headers if required) ENDIF() ENDIF() Regards, Alexey. cheers Mattias On Fri, Jan 23, 2015 at 9:25 AM, Alexpux alex...@gmail.com wrote: 23 янв. 2015 г., в 10:59, Robert Osfield robert.osfi...@gmail.com написал(а): Hi Alexey, On 22 January 2015 at 21:02, Alexey Pavlov alex...@gmail.com wrote: All defines are present in glext.h for mingw-w64. Wonder why they not defined. See: https://github.com/Alexpux/mingw-w64/blob/master/mingw-w64-headers/include/GL/glext.h Perhaps CMake is using the Windows gl.h rather than the mingw one. Have a look to see what CMake has selected for the path to the OpenGL headers - the variable is OPENGL_INCLUDE_DIR:PATH. Here: https://github.com/Alexpux/mingw-w64/tree/master/mingw-w64-headers/include/GL You can see that «gl.h» is also present. So maybe need include not only this header? Alexey. 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] Loading .obj files inefficiently
Hi Jeremy,
I just had a quick look at the code. It's rather dated.
I'd be inclined to replace almost all the code in the
ReaderWriterOBJ::convertElementListToGeometry() method to one that uses
DrawElementsUShort/UInt, and GL_TRIANGLES when handling the POLYGON, with
the local method breaking up the polygons. One could possible use the glu
tesselation routes if the POLYGON has concavities.
Feel free to scalpel to it and we can then discuss the results :-)
Robert.
On 25 January 2015 at 05:30, Jeremy jswig...@gmail.com wrote:
I am working on a visualization/debugging UI and in the process of
displaying the scene graph to a tree view in my gui, I noticed that there
appears to be an issue with the .obj file loader that could be improved
significantly.
The first problem I came to is seeing that the resulting osg::Geometry
node that comes from loading the obj had 191,000+
osg::Geometry::getNumPrimitiveSets(). Turns out, the obj reader creates
a osg::DrawArrays for each individual face of the model, and my particular
model 191639 faces.
Not a huge deal I thought, I'll add a quick option to the reader to
optimize it before returning it, as I'm not so comfortable butchering up
the ReaderWriterOBJ::convertElementListToGeometry code as of yet.
if ( localOptions.mergeMeshes )
{
osgUtil::Optimizer opt;
opt.optimize( node, osgUtil::Optimizer::MERGE_GEOMETRY );
}
Surprisingly, this didn't work, and the culprit I found is that the
optimizer cannot merge geometry forTRIANGLE_FAN, which is what was being
used in ReaderWriterOBJ::convertElementListToGeometry for triangles.
Changing this to TRIANGLES allowed the optimizer to merge this huge number
of primitive sets down to 1.
Here's a shot of the UI after my fixes where the model has been merged as
desired.
https://www.dropbox.com/s/07t5zk7hw8jp2r7/Screenshot%202015-01-24%2023.06.38.png?dl=0
Hopefully someone on the dev side can at least change the TRIANGLE_FAN
part trivially, though it would be nice if the reader didn't create such
bad primitive sets up front.
Thanks
Jeremy
___
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] Loading .obj files inefficiently
I need to maintain my focus on developing my app, so I'm not sure when I
could get to it. My small temporary fixes are enough to get me by
satisfactorily for the time being. It may not be worth me personally
spending time on, since ultimately my app will load content through other
channels than obj files(network mostly). I wanted to at least mention it so
someone that has a bigger stake at the obj file support might be interested
in improving it.. I happened to notice it when my code that constructs the
GUI hierarchy tree view ground to a halt trying to populate the tree with
191k items for each individual face.
On Sun, Jan 25, 2015 at 4:01 AM, Robert Osfield robert.osfi...@gmail.com
wrote:
Hi Jeremy,
I just had a quick look at the code. It's rather dated.
I'd be inclined to replace almost all the code in the
ReaderWriterOBJ::convertElementListToGeometry() method to one that uses
DrawElementsUShort/UInt, and GL_TRIANGLES when handling the POLYGON, with
the local method breaking up the polygons. One could possible use the glu
tesselation routes if the POLYGON has concavities.
Feel free to scalpel to it and we can then discuss the results :-)
Robert.
On 25 January 2015 at 05:30, Jeremy jswig...@gmail.com wrote:
I am working on a visualization/debugging UI and in the process of
displaying the scene graph to a tree view in my gui, I noticed that there
appears to be an issue with the .obj file loader that could be improved
significantly.
The first problem I came to is seeing that the resulting osg::Geometry
node that comes from loading the obj had 191,000+
osg::Geometry::getNumPrimitiveSets(). Turns out, the obj reader creates
a osg::DrawArrays for each individual face of the model, and my particular
model 191639 faces.
Not a huge deal I thought, I'll add a quick option to the reader to
optimize it before returning it, as I'm not so comfortable butchering up
the ReaderWriterOBJ::convertElementListToGeometry code as of yet.
if ( localOptions.mergeMeshes )
{
osgUtil::Optimizer opt;
opt.optimize( node, osgUtil::Optimizer::MERGE_GEOMETRY );
}
Surprisingly, this didn't work, and the culprit I found is that the
optimizer cannot merge geometry forTRIANGLE_FAN, which is what was being
used in ReaderWriterOBJ::convertElementListToGeometry for triangles.
Changing this to TRIANGLES allowed the optimizer to merge this huge number
of primitive sets down to 1.
Here's a shot of the UI after my fixes where the model has been merged as
desired.
https://www.dropbox.com/s/07t5zk7hw8jp2r7/Screenshot%202015-01-24%2023.06.38.png?dl=0
Hopefully someone on the dev side can at least change the TRIANGLE_FAN
part trivially, though it would be nice if the reader didn't create such
bad primitive sets up front.
Thanks
Jeremy
___
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] [ANN] [General Purpose Graphical Introspection]
mp3butcher wrote: the problem i try to solve is generalized runtime graphical programmation. I'll try to stay simple: pmoc generates customisables and extendables graphical components embedding objects methods and they can be use in a generic Editor to demonstrate the ability to do runtime graphical programmation: The paste feature introspects the selected object and calls the method that can be used with copied object as a parameter. If several methods fit the couple (class of selected /class of copied) then a menu popup in order to ask you which you want to call. So It avoids programmation and compilation steps as all is done at runtime. osg is perfect experiment candidate to be instrumentalised with pmoc as: - osg objects have an expression in 3D (not purely logic) - all objects of all libraries are homogenous (no articulation problem between libs) - objects have a lot of single parameter arguments (perfect for the generated nodal logic) - osg provides serialization!! But more globally (and from my point of view), pmoc allows to highlight features (and so on bugs:) ) of C++ heterogenous (or not in the case of my osg experiment) libraries and allows to mix them in a generalized QT graphical context in order to manipulate them. Personnally, I use osg4noob to introspect my own unfinished classes when i'm not sure of what I happen (and so try to fix them graphically before to hardcode in c++) or when the scene is becoming too complex/dirty to be understandable/manipulated programmatically. It saves me a lot of coding time and so I thought the underlying pmoc was an interesting project to developp deeper as it is ( i repeat it again) not restricted to osg instrumentalisation. +: -MetaModel doesn't require code instrumentalisation(like osgintrospection) , it generates the Qt instrumentalisation. -QT based, generated components are easy to customize in C++ and to manipulates at runtime in QML ( unlike osgintrospection;) ) -pmoc is inscriptible in an automated compilation pipeline sources---pmoc--customisablesources--moc--yourfavoritecompiler--ComponentPlugin -: (unlike osgintrospection it is not based on doxygen) -pmoc relies on a C++syntaxic parser so it doesn't read all library headers (For my eternal damnation with the C++ grammar ...) -pmoc need total rewriting pmoc!=cppintrospection pmoc is not wrapping but boxing it allows to inject at runtime natively created object in a box that is in charge of calling method on it kornerr wrote: So what problems does your software solve exactly? I couldn't understand it. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62471#62471 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] compositeView in multithreaded Win32 MFC MDI application
Hi! We have a mature app, that uses Microsoft's MFC library for GUI management. Application windowing model is MDI. I have to render a multiple 3D scenes in different MDI childs, which are created elsewhere. So, I should attach OSG context to existing window. The threading model of our app is messy, so it is a possibility, that calls will be made from different threads. Is there any general sources of information, how to use correctly compositeView in this environment, and how to correctly attach View to MDI child's client window? Thank you! Cheers, Dan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62465#62465 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
