Hi All,
One of the changes I've discussed before, but as yet no made, is to
simplify osg::Geometry so that it drops the index arrays that you can
currently associated for vertex, normal, colour, texcoord arrays.
These index arrays aren't supported by OpenGL, instead have to be
emulated by
I have now started looking into what changes would be required to
osg::Geometry and have decided to make a copy of Geometry called
GoemetryNew and cut this down to see how easy it will be clean this
class up and what the knock on effects might be. Now I have dived in
and begun the process one
On 4 June 2013 09:42, Robert Osfield robert.osfi...@gmail.com wrote:
My current action plan is to get GeometryNew.cpp to build and run with
the osggeometry example
I have now got my quick clean up of Geometry as GeometryNew class with
osgeometry compiling and running correctly. My GeometryNew
Robert,
I think it's better to check it in.. Others would have the opportunity to
participate or evely siltently read the code and learn. Maybe there aer others
out there reading changes and try to learn as I do it usually ( If time
permits).
Regards,
Torben
--
Read this
Hi,
Have you looked at osgPoster?
thanks,
Torben
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=54421#54421
___
osg-users mailing list
osg-users@lists.openscenegraph.org
On 4 June 2013 10:21, Torben Dannhauer tor...@dannhauer.info wrote:
I think it's better to check it in.. Others would have the opportunity to
participate or evely siltently read the code and learn. Maybe there aer
others out there reading changes and try to learn as I do it usually ( If
Dear Ladies and Gentlemen,
I am currently working on developing a visualization tool using
OpenSceneGraph. I am supposed to develop a branch for the tool to work on
Android.
I am having some problems and my experience with OSG cannot really help me
pass it.
In few Words
- - My
HI Mohmoud,
I haven't programmed on Android yet, but as CompositeViewer can be
made to work with a single GraphicsContext I see no reason why you
can't just create a GraphicsWindowEmbedded and assign this to each of
your View's Camera, with a separate Viewport selecting the part of the
window you
Hi Robert,
On Tuesday, June 04, 2013 09:42:10 Robert Osfield wrote:
Thoughts?
Great idea!
I see that the GeometryDeprecated is still needed.
... that means we will need this at least.
The begin/end emulation code could then probably move to wherever you move the
GeometryDeprecated class.
HI Mathias,
On 4 June 2013 13:53, Mathias Fröhlich mathias.froehl...@gmx.net wrote:
I see that the GeometryDeprecated is still needed.
... that means we will need this at least.
I don't think it'll be too difficult to maintain, and it'll be really
useful to old Geometry held in the existing
Hi,
On Tuesday, June 04, 2013 14:12:21 Robert Osfield wrote:
May be this is also an opportunity to throw out the deprecated dlists?
I don't reason a need to drop display lists in osg::Geometry, at least
at this point. Display lists are rather orthogonal to the rest of the
API.
One
Hi Robert,
Would you consider changing BIND_PER_PRIMITIVE code to do some kind of
internal conversion to fast path rendering, such as expanding the arrays
by 3x (duplicating the color or normal for each vertex) so that it can
use the per-vertex rendering path? I have certainly written code
Hi David,
On 22 May 2013 20:55, Robert Osfield robert.osfi...@gmail.com wrote:
I'm inclined to think it's safe to remove it as it's for a defunct product
and likely to mostly out of use now.
As there was no response in support for maintaining the .geo plugin,
and Carbon Graphics has long been
Hi Peter,
On 4 June 2013 14:29, Peter Amstutz peter.amst...@tseboston.com wrote:
Would you consider changing BIND_PER_PRIMITIVE code to do some kind of
internal conversion to fast path rendering, such as expanding the arrays by
3x (duplicating the color or normal for each vertex) so that it
Hi,
I tried changing this method
[code]_viewer-setUpViewerAsEmbeddedInWindow(x, y, width, height);
[/code]
by creating my own GraphicsWindowEmbedded and assigning it to the camera
[code]osgViewer::GraphicsWindowEmbedded* _gwe = new
osgViewer::GraphicsWindowEmbedded(x,y,width,height);
Hi Robert,
This is totally reasonable and on balance I agree with your reasoning.
I thought the feature deserved a little discussion before being sent
quietly into the night :-)
On 6/4/2013 9:44 AM, Robert Osfield wrote:
I believe that a fast path only osg::Geometry is worthy enough goal to
Hi Peter,
On 4 June 2013 15:34, Peter Amstutz peter.amst...@tseboston.com wrote:
This is totally reasonable and on balance I agree with your reasoning. I
thought the feature deserved a little discussion before being sent quietly
into the night :-)
;-)
The reason for me to raise this topic
Hi All,
I have now taken the next step and added the following methods to osg::Array:
/** Specify whether the array data should be normalized by OpenGL.*/
void setNormalize(bool normalize) { _normalize = normalize; }
/** Get whether the array data should be normalized
Thanks Robert. I'll spend some time getting the newest OSG working here,
and then try applying my patch, and submit it for your perusal.
Eric
On Mon, Jun 3, 2013 at 7:26 AM, Robert Osfield robert.osfi...@gmail.comwrote:
Hi Eric,
On 3 June 2013 11:42, Eric Sokolowsky esok@gmail.com
Hi,
Just a coment. Deprecate inmediate mode is also and advantage w.r.t. mobile
devices. OpenGL_ES does not implement inmediate mode since its first
version, and display lists are no supported since OpenGL_ES 1.1. So it will
be good for those starting with ES and OpenSceneGraph.
Cheers.
On 4 June 2013 17:56, Jordi Torres jtorresfa...@gmail.com wrote:
Just a coment. Deprecate inmediate mode is also and advantage w.r.t. mobile
devices. OpenGL_ES does not implement inmediate mode since its first
version, and display lists are no supported since OpenGL_ES 1.1. So it will
be good
Hi Robert,
These changes sound good. I'm all for cleaning up the Geometry class.
You mentioned implementing some sort of backwards compatibility for the
serialization plugins. Does that mean existing osg files (osg, ive, osgb,
etc...) that use indices will automatically fall back to the
Hi creature,
yes, the launch function is exactly where you should call those npp-functions.
You get the device pointer by calling myBuffer-map(osgCompute::MAP_DEVICE).
If you want to get access to the internal texture memory, call
myBuffer-map(osgCompute::MAP_DEVICE_ARRAY) and cast the void*
Hi sajis997,
CUDA comes with two programing interfaces: a Driver API and a Runtime API. We
currently only support the built in Runtime API with our osgCuda
implementation.
However it has nothing to do with the display driver or the compute capability.
Thus, a gtx 560m and cuda tool-kit 4.2
Hi Farshid,
On 4 June 2013 18:27, Farshid Lashkari fla...@gmail.com wrote:
You mentioned implementing some sort of backwards compatibility for the
serialization plugins. Does that mean existing osg files (osg, ive, osgb,
etc...) that use indices will automatically fall back to the
Hi sajis997,
The export file defines EXPORT/IMPORT macros for all functions in our osgCuda
library in case you are using dynamic libraries (i.e. you have set the
DYNAMIC_LINKING flag to true in CMake).
Nice to hear that you are going to extend osgCompute to OpenCL.
I am also in E-Mail contact
Hi sajis997,
You are right. osgCuda::Buffer is not documented yet. I am on it!
Regards,
Jens
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=54452#54452
___
osg-users mailing list
Hi sajis997,
You have to install the dynamic libraries first. Otherwise he can't find the
libraries. After installing the trace demo should work perfectly.
Cheers,
Jens
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=54453#54453
Hi All,
I have now completed the removal of ArrayData container and all slow
path support from GeometryNew. The size is now down to less than
2/3rd the size of the original Geometry.cpp. The largest bloat left
is with helper functions for verifying and correcting bindings, but I
now believe
Hi,
I have switched my rendering stuff to deferred rendering, and I noticed some
problems around the edges of the hills in the terrain (see attached picture)
I write 3 buffers:
-color
-normal
-position (fragment position in world coordinates)
I tried finding a problem in the buffers around the
robertosfield wrote:
The PreserveDataType and AttribDivisor are entirely
new and are intended to support new extensions being added to the OSG
- but their implementation will have to wait till the GeometryNew
refactor is further down the road.
This is great !
robertosfield wrote:
Does anyone know: what is the default texture filter mode (for 3d textures)
when you do not explicitly set it?
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=54457#54457
___
osg-users mailing list
On 4 June 2013 22:49, Bram Vaessen bram.vaes...@gmail.com wrote:
Does anyone know: what is the default texture filter mode (for 3d textures)
when you do not explicitly set it?
The default filtering for a texture objects is defined in the
Texture::Texture() default constructor and is (from
Hi Aurelien,
On 4 June 2013 21:33, Aurelien Albert aurelien.alb...@alyotech.fr wrote:
robertosfield wrote:
The naming of Binding is something I'm note yet sure of, with the
introduction of AttribDivisor the binding becomes a bit less clearly
defined as well. Not sure what to make of this
34 matches
Mail list logo
