The OSG's LookAt implementation is *exactly* the same as gluLookAt,
the parameters and the maths are all identical. I made sure this was
the case to enable users to map GL code across easily as well as for
us to be able to leverage existing GL documentation.
The core OSG doesn't have a fixed
Hi Pawel,
On Thu, 9 Aug 2018 at 17:59, Paweł Księżopolski
wrote:
> If you are still in sponge mode - I just released new version of my Vulkan
> renderer, where you can find few articles linked from README.md.
>
> These articles describe some of the important aspects of my renderer
>
On Sat, 4 Aug 2018 at 17:24, Sam Brkopac wrote:
> Most of the OSG examples use Geodes. What is the type you would use for a
> modern scene graph?
Most of the examples pre-date the change to allow Drawables to be
added directly to the scene graph. Since there are so many examples
it's a bit of
Hi Sam,
Geode used to be the leaf node in the scene graph that could only have
Drawable as children, no traditional node types could be added to a
Geode, so with older versions of the OSG what you are attempting
wouldn't even compile.
I don't recall the exact date, but in the last few years I
Hi Sam,
I don't have time to look at build end user code today but I have had
a quick glance at the example and the first thing that jumped out as
add to me was:
osg::ref_ptr drawable(new osg::Geode);
drawable->setName("lnoflags");
geode.addChild(drawable);
Adding a Geode to a
Hi Dan,
I'll be focusing on Vulkan work today so won't look into this right
away. Next week I'll set aside a day for OSG maintenance and
hopefully will be able to look at this then.
Robert.
On Thu, 2 Aug 2018 at 15:49, Daniel Emminizer, Code 5773
wrote:
>
> Hi Robert,
>
> I think I've found a
On Tue, 31 Jul 2018 at 15:40, Chris Hanson wrote:
> I think Brede Johansson wrote that loader once upon a time. I'm hoping to
> connect with him in Oslo this week. Maybe I'll ask him about this if I do.
Brede's original OpenFlight plugin back in fall of 2000 was our first
major community
Hi Dan,
Changes looks good to me, just merged. Nice to see a bug fix/feature
improvement that removes three times as much code as it adds! :-)
Cheers,
Robert.
On Tue, 31 Jul 2018 at 16:48, Daniel Emminizer, Code 5773
wrote:
>
> Hi Chris,
>
>
>
> I think that would be good. I have some
Hi Glenn,
Thanks for the note. When I just back onto OSG maintenance work I'll
have a look into it. Should be in the next week or two.
Robert.
On Tue, 31 Jul 2018 at 15:54, Glenn Waldron wrote:
>
> Robert,
> I would like to make you aware of two thread-safety issues in osgText:
>
>
Hi Dan,
I'm not at a point where I can easily switch over to thinking about
OSG code written by others so rather than jump it right now I'll ask a
simple question that might help point you in a direction worthy of
investigation.
FYI, I'm not the author of the OpenFlight plugin so am in the same
Hi Sam,
I have just checked the history of CameraMaipulator, I must have
missed this the addition of FIXME back in.
Date: Wed Aug 28 14:27:18 2002 +
Updates, from Neil Salter, to comments etc to osgGA which add better
explanations of how each of the classes operates.
I think
On Mon, 30 Jul 2018 at 15:59, Andrew Cunningham wrote:
>
> Back on the original topic :)
>
> This is a really simple QtOSGWidget that I used as a starting point for an
> OSG widget in a QDialog. Simple and works fine.
>
> https://github.com/vicrucann/QtOSG-hello
Just had a quick look at the
On Mon, 30 Jul 2018 at 11:00, Wojciech Lewandowski
wrote:
> I find your response as rather harsh and wonder why it hits me. Thats why I
> feel the need to reply.
My response is blunt because I'm frustrated that despite my best
efforts to community clearly to the community and asking
Hi Wojtek,
On Mon, 30 Jul 2018 at 08:53, Wojciech Lewandowski
wrote:
> I understand my setDrawBuffer / setReadBuffer observation was probably not
> the only problem. But I believe this one is genuine problem that should not
> be neglected. So I decide to write this small followup and elaborate
Hi Tom,
On Mon, 30 Jul 2018 at 00:39, Tom Williamson wrote:
> Turns out it was a scoping issue (as suggested by Robert), is more or less
> working as expected now...
Good to hear it's resolved.
> Unfortunately now have to deal with shader issues when using the multipass
> rendering, as my
Hi Jinh,
osg::Notify has no relation to the stack traces, it's simply debug
output to help track what is being done by the OSG, it may sometime
pick out an issue that eventually causes a crash, but it's really
nothing more as info system.
As to the cause of the crash, there is no way for use to
Hi Damian,
The glEnable/glDisable will be done directed by your scene graph via
the StateSet::setMode(GLenum,..), so simply remove the
setMode(GL_POINT_SPRITE).
Robert.
On Sun, 29 Jul 2018 at 14:24, Damian Dixon wrote:
>
> Hi,
>
> I have a build of OSG 3.6.2 for GLCORE for Mesa 18.0.5, Intel HD
?!?! gmail just sent the email mid sentence
> That exactly the same can be said for the OSG. Doesn't mean
Mean't to say:
On Sat, 28 Jul 2018 at 10:20, Robert Osfield wrote:
> > Now, there are huge firms that adopted Qt for decades and run multi billion
> >
recurrent
> issue for over a decade and a half I follow OSG.
>
>
> I have used Qt and OSG back in 2003, 15 years ago with success.
>
> > On Jul 27, 2018, at 12:03 PM, Robert Osfield
> > wrote:
> >
> > Hi Andrew,
> >
> >> On Fri, 27 Jul 2018 at 17:1
Hi Andreas,
When you use GLCORE you have to provide your own shaders to do rendering.
Unless you really have to use GLCORE for portability reasons - such as
OSX or to avoid crappy driver issues, I would recommend just sticking
with the default build of the OSG where you can mix and match old
Hi Andrew,
On Fri, 27 Jul 2018 at 17:14, Andrew Cunningham wrote:
> I would agree QT is not perfect but on the flip-side
> - It is the 'last man standing' of x-platform UI's.
This is down to the weakness of the alternatives rather as much as the
strength of Qt.
> - It's actively developed
Thanks for the test example. I don't have time right now to look into
it, but once I've achieved a couple of milestones on my Vulkan work
I'll return to clear up outstanding OSG bugs. Do I need any special
data to reproduce the crash?
On Fri, 27 Jul 2018 at 09:24, Ale Maro wrote:
>
> Hi Robert,
On Thu, 26 Jul 2018 at 22:34, Stuart Mentzer wrote:
>
> Hi Andrew,
>
> I had no luck despite trying many variations. I had to put this work aside
> for a while with the plan to circle back and check for osgQt updates now and
> then. But if someone adds some ideas here I'll try them.
>
>
> To
Hi Jinh,
First thing I would try is to run your application single threaded.
If this fixes the crash then it would indicate a threading issue with
how you are going about adding/remove elements of the scene graph.
You don't describe any of details of what threads are doing what so I
can't
HI David,
I'm don't have time to look at the code right now so will just provide
some general hints. The serailizers have SO version built into them
so you can add or remove components of the serializer based on the SO
version of the OSG. There are number of places in the OSG serailizers
that
Hi Tom.
My best guess would be that the ITK image data is being deleted prior
to the graphics thread gets a chance copy the data into OpenGL. Try
either copying the data into the osg::Image and let osg::Image then
manage the lifetime of it's own data, or prevent the ITK image data
from getting
Hi Ale,
The KdTree was refactored in 3.6.x to add support for points and lines
and PolytopeIntersector. While there has been lots of internal
changes in it, it of course shouldn't crash.
At this point in time I don't have any idea where the issue stems
from. Could you create a small example
On Mon, 23 Jul 2018 at 11:52, michael kapelko wrote:
> Continuing the `running in real life` topic: yesterday I ran 20 km for
> the first time, took me about 3 hours.
Well done, baby steps, keep at it and you'll get further and faster.
> I was totally drained. I wonder
> how people make 95
Hi James,
On Fri, 20 Jul 2018 at 15:59, James Davis wrote:
> I suppose my confusion comes from the original issue I was seeing... the very
> slow loading of ive and osg files (even though obj's are slow too)
>
> So.When osgconv creates an ive and/or osg formats from a obj, does the
> obj
Hi James,
The checks are needed in Geometry,cpp and Drawable.cpp, if you've
changed these you will likely be breaking something else. You might
not be see any issues yet, and might not ever, but as I don't know
exactly what you've changed I can't say. All I can say it's not
really fixing the
Hi Glenn,
This is a new one for me :-)
My guess is that the a GLyphquad has been inserted in into the
Text::_textureGlyphQuadMap but it's primitives member hasn't had
filled in with anything.
Do you know if this happens with any of the standard osgtext examples?
Cheers,
Robert.
On Thu, 19 Jul
On Thu, 19 Jul 2018 at 16:19, James Davis wrote:
> I wanted to see if anyone had a chance to come up with some test code I might
> could try out. Sorry if I sound like I'm nagging. :?
I haven't personally looked at the code since I last replied. Perhaps
others have.
You have full access to
Hi Stuart,
On Tue, 17 Jul 2018 at 23:14, Stuart Mentzer wrote:
> Thanks for the info @davisjamesf. I wish I knew what secret sauce was needed
> to get this running. I'll keep trying and maybe I'll have luck with some
> future osgQt release.
>
> If you or anyone have some example code for a
Hi Werner,
The values are averaged as otherwise they'd jump around so much that
they would be un-readable blur.
The exact values are all collated in the the various osg::Stats
objects, so perhaps you can have a look at these.
As a general note, OpenGL timing data is not deterministic, this is
On Fri, 13 Jul 2018 at 20:30, werner.modenb...@texion.eu
wrote:
> Thanks. Any suggestion how to know this?
Have a look at the osggoucull example.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Hi Werner,
The best way to handle the vertex shader moving geometry to new
locations is to use a custom osg::DrawableComputeBoundingBoxCallback
that you assign the the drawable that you are using for instancing.
You'll want to return a BoundingBox that encompasses all the positions
that the
On Thu, 12 Jul 2018 at 17:59, Igor Spiridonov wrote:
> No, why would I have a circular reference?
The OSG doesn't generally leak unless you do something pretty odd, the
codebase is pretty heavily tested now.
So we can only guess as to what might be wrong. Circular references
is one
On Thu, 12 Jul 2018 at 17:52, Guy Volckaert wrote:
> I also looked at the osg-submissions archives and could not find any trace of
> this change. I went back as far as June 2017.
Most submissions now come it via pull requests on github.
Robert.
___
Hi Igor,
On Thu, 12 Jul 2018 at 16:24, Igor Spiridonov wrote:
> I have found the memory leak cause. Look like I don't understand how osg
> works.
> I have a root node and its child node. I add UpdateCallback to the root node
> and inside this callback i remove child nod's drawables and add
Hi Guy,
The commit that changes this was:
ommit bb84f1ea3c23625a645b9c2848202bca7c566efb
Author: Konstantin S. Matveyev
Date: Sat Jan 13 15:46:53 2018 +0300
osgViewer::ViewerBase setThreadingModel func fix: should not start
threading, must only restart
Off the top of my head I only
On Wed, 11 Jul 2018 at 23:39, Rob Ewbank wrote:
>
> Thanks Robert, I have been looking through the code and have merged two
> branches, one which has been changed to work with OSG 3.4.1 and the master.
>
> Osgocean seems to do a few weird tricks with shaders and rendering that cause
> issues in
Hi Marlin,
On Wed, 11 Jul 2018 at 19:59, Rowley, Marlin R
wrote:
> Are you suggesting that I compute the world space normal in the
> application and pass it to the shader? I absolutely need world space
> coordinates. If so, how would I get the normal of the triangle before
> evaluating the
Hi Marlin,
It can be done, but I strongly recommend that you don't go transforming
vertex or normal data into world coordinates in the shader. I know there
are some published algorithms that do this but it's a really bad practice
and you shouldn't follow it as precision issues on only proper
HI Igor,
You don't provide enough information to know what might be causing the
increasing in memory so we can't provide any specific guidance. In
general the OSG's memory management is pretty solid, there are areas
where data is cached either explicitly or implicitly due to
restrictions due to
On Wed, 11 Jul 2018 at 14:34, Igor Spiridonov wrote:
> Unfortunately I can only use osg 3.2. Your advice to implement a texture with
> all texts included sounds very promising.
We are now on 3.6.2, so 3.2 is pretty out of date, there many feature
improvements and bug fixes in 3.6.2 that aren't
Hi Nick,
I regret merging the osgUtil::DelaunayTriangulator submission all
those years back. While it comes close to working OK it just isn't
robust enough and making it robust will require support for a robust
incircle/same side test that isn't trivial to implement, and require
some novel
Hi Ryan,
The osglight example just just the fixed function pipeline and doesn't
provide any shaders.
What you describe sounds like an Intel driver bug. The best thing you
can do is check for latest Intel drivers.
Robert.
On Mon, 9 Jul 2018 at 21:51, Ryan Thoryk wrote:
>
> I recently started a
Hi Igor,
You can implement your own texture using osg::Geometry and reuse the
osg::Font's ability to generate the texture atlas. It's a bit
involved to get all the alignment etc. issues right but it's perfectly
doable and does perform very well.
However, before you dive off in a complicated but
Hi Nick,
On Mon, 9 Jul 2018 at 12:26, Trajce Nikolov NICK
wrote:
> > are changes for changes sake rather than likely to make any
> functional difference
>
> I knew you will have comments ;-). It works just fine with these changes but
> yes, you are right - quick and somewhat dirty. So can
I have other tasks to get on with today so I won't keep pursing this
loading speed regression right away, if others want to look at before
I come back to it then the way I think it should be tackled is be
changing the loader to so it creates a small set of primitives using
GL_TRIANGLES rather than
Hi Nick,
I had a quick look at your changes and it seems to be like most of
them are changes for changes sake rather than likely to make any
functional difference. For non ascii char support I think what you'd
actually want to do is change the XmllNode::Input::string _buffer
member var to a
I have established it's the osgUtil::optimizeMesh(geometry); call in
the 3.6 obj plugin that is causing the slow down in .obj loading.
When writing the model out to .osgt without the optimization you can
see the likely reason why this dataset might be triggering issues:
PrimitiveSetList
Now tested the model with 3.4 - much faster:
$ time osgconv SquareTest.obj test_34.osgb
Data written to 'test_34.osgb'.
real0m3.842s
user0m3.112s
sys 0m0.728s
I've looked at the diffs between 3.4 and 3.6 for the obj plugin, the
only difference that stands out as a possible cause is
Hi James,
The file was too big to distribute on the osg-users mailing list that
mirrors the forum so I pulled down the data from the forum and can see
the loading performance issue when using OpenSceneGraph-3.6.2:
$ time osgconv SquareTest.obj test.osgb
Data written to 'test.osgb'.
real
Hi Rob,
I am afraid that osgOcean is a 3rd party NodeKit that was written a
long time ago and as far as I'm aware has seen active development or
widespread use across the OSG community, so the chances of having
others that have the knowledge to help will be quite low. I don't
know if the
Hi Igor,
The OSG uses OpenGL display lists by default, or
VertexBufferObjects/VertexArrayObjects when enabled via
osg::Geometry::setUserVertexBufferObjects(true) +
setUserVertexArrayObject(true). These GL objects cache the vertex
data within GL, so if you want to update the vertex data you need
Jay! Another sleepiness night due to the stress of how to deal with
unplanned actions of others. I'm not one who thrives on stress, and
not one who enjoys living off 2hrs of sleep. I hate existing like
this, it's neither healthy for my short or long term health.
What makes things difficult is
On Sat, 30 Jun 2018 at 03:51, Chris Hanson wrote:
>
> Ok. I've done this.
>
> https://github.com/KhronosGroup/Vulkan-Ecosystem/issues/36
>
> Maybe that will get their attention and some response.
Guys, I'm in transit on holiday, it's supposed to be a time for me to
relax, not to start thinking
Hi All,
I am taking a weeks holiday next week so will be offline till 9th of June.
On my return I'm hoping that I won't return to a barrage of "oh dear
now we've tested it 3.6.2 we found it has a bug..." but given this
always happens after a release despite all the calls for testing this
is
On Fri, 29 Jun 2018 at 17:49, Maxim Stere wrote:
> I understand your opinion, but respectfully disagree.
It's not your opinion that counts. It's others it's how others
respond that counts when you are in public. It's *HORRIBLE* to see
disregard for the feelings of others. The fact you have no
On Fri, 29 Jun 2018 at 12:54, Maxim Stere wrote:
> Very well.
> The name is actually a psychological test. It means different things
> depending on your outlook and demeanor. If you are more negative and take a
> more snap judgement outlook, then yes, it means something negative to you. If
>
have shake down and improve this release,
well worth the effort creating solid foundations for graphics app
development.
Cheers,
Robert.
-- ChangeLog since 3.6.1
Fri, 29 Jun 2018 10:56:01 +0100
Author : Robert Osfield
Updated date for 3.6.2 releases
Fri, 29 Jun 2018 10:54:13 +0100
Author : Robert
On Fri, 29 Jun 2018 at 04:29, Maxim Stere wrote:
>
> Made a PR #570
>
> I will investigate windows GL libraries further, and see if I can make the
> Kronos GL headers work on windows without much modifications.
> If I succeed I'll make another PR with fixes that will give users full GL
>
Hi Maxim,
The default to BoundingBoxf and BoundingSphref is partly a historical reason.
Scene graphs traversals are memory bandwidth limited so you only want
to pay for the extra memory size if there is specific value in doing
so.
Robert.
On Fri, 29 Jun 2018 at 05:00, Maxim Stere wrote:
>
>
On Thu, 28 Jun 2018 at 14:53, Eric Sokolowsky wrote:
> Trademark holders *must* defend their trademarks, or they lose them.
Indeed this is true. It's only part of the story though.
Khronos mission is to develop and promote open APIs, as part of this
they trademark projects they undertake, they
On Thu, 28 Jun 2018 at 13:57, Robert Osfield wrote:
> The original osg::Uniform class is a bit of unwieldy mess. In
> hindsight we shouldn't have gone for this particular implementation as
> it's a bit too open ended.
As a bit of background, Mike Weiblen with a bit of input from mysel
On Thu, 28 Jun 2018 at 13:06, Sebastian Messerschmidt
wrote:
> @Robert:
> Any insights?
The original osg::Uniform class is a bit of unwieldy mess. In
hindsight we shouldn't have gone for this particular implementation as
it's a bit too open ended.
In master I have written a osg::UniformBase
Hi Orphen,
On Thu, 28 Jun 2018 at 07:52, Orphen wrote:
> I tried to build the Doxygen documentation on master today using Doxygen
> 1.8. The Doxyfiles are a bit dated, and some parts are malformed (ex:
> environment variable expansion). This causes Doxygen to report some
> errors and then give
Hi All,
My plan is to tag 3.6.2 tomorrow, as there were two fixes yesterday
that I merged with the 3.6 branch I have made release candidate 3:
https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.2-rc3
Thanks for testing and feedback :-)
Robert.
-- ChangeLog since rc2
Hi Dan,
The PR looks like an acceptable level of hackiness to resolve this
problem so I've merged this.
There is limit in how much we should go chasing our tails on this
suff, there is fixed function code all over the OSG so it'd be a
massive undertaking to try and find fall-backs for all these.
Hi Werner,
On Wed, 27 Jun 2018 at 15:14, Werner Modenbach
wrote:
> I'd really like doing that. Unfortunately I'm on Windows and the only
> development environment is Qt.
> So I cannot even create a small project outside Qt.
> But honestly I tend to believe it's something in OSG.
> Really the
code to be just OSG, except createScreenQuad() but
> that should not really matter.
>
> Thanks
>
> - Werner -
>
> Am 27.06.2018 um 15:44 schrieb Robert Osfield:
>
> Hi Werner,
>
> You appear to be included reference to calls and classes that aren't
> in the OpenS
Hi Werner,
You appear to be included reference to calls and classes that aren't
in the OpenSceneGraph, are you using a 3rd party library that is
providing these?
At this point I can't see a way of helping you as there bit doing the
set up are unknown to us.
Robert.
On Wed, 27 Jun 2018 at 13:53,
Hi All,
A PR has just been placed on the openscenegraph github repository:
https://github.com/openscenegraph/OpenSceneGraph/pull/567
I am bit surprised by the need for this PR as I had assumed that the
code base was being rested pretty well under Windows with all the
recent stable release
Hi All,
I have tagged the 3.6.2 release candidate 2:
https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.2-rc2
Please test and let us know of success or failures :-)
Cheers,
Robert.
-- Changes since 3.6.2-rc1
Wed, 27 Jun 2018 09:06:58 +0100
Author : Robert Osfield
Hi Igor,
Once you pick an appropriate font resolution for the size of the text
on screen it should be appear pretty smooth. If this isn't happening
then we'll need more information about your OSG version, hardware, OS,
a screen shot, whether the osgtext example renders decent text.
Cheers,
HI Guy,
On Tue, 26 Jun 2018 at 20:10, Robert Osfield wrote:
> As for the creation or the Settings object on the heap, as it's a
> local new/delete and operation within a single thread it is probably
> safe to replace with an object on the stack.
I have implemented this an
Hi Guy,
Just how many separate LineSegmentIntersection and Drawables are you
trying to intersect with?
As for the creation or the Settings object on the heap, as it's a
local new/delete and operation within a single thread it is probably
safe to replace with an object on the stack.
Robert.
On
Hi Maxim,
On Tue, 26 Jun 2018 at 14:59, Maxim Stere wrote:
> We don't want to do anything like GL3_WINDOWS since most likely that will
> have to have a new external dependency.
?? So you don't want to install the official glcorearb.h for some
reason, and me suggesition of just relying upon
HI Maxum,
On Mon, 25 Jun 2018 at 21:29, Maxim Stere wrote:
> It does not work like that on windows. Windows by default does not come with
> gl3.h or GLcorearb.h and neither does Visual Studio, so you need to install
> extra dependencies to make the OSG GL3 or GLCORE profiles to work. Otherwise
On Mon, 25 Jun 2018 at 17:01, Chris Hanson wrote:
> Ok, so does anyone have any actual current contacts with Khronos? I have a
> few distant ones but they aren't terribly responsive.
I have met a few from the ARB/Khronos over the years but don't have
any personal contacts. If people do then
ll be glad to learn if there is some other and more recommended way to do
> it.
>
> Many thanks for your never ending patience.
>
> - Werner -
>
> Am 25.06.2018 um 14:59 schrieb Robert Osfield:
>
> Hi Werner,
>
> What are you using the ABSOLUTE_RF Camera's for? My g
On Mon, 25 Jun 2018 at 15:59, Maxim Stere wrote:
> Would it help if I submit a fix for windows to make GL3 work out of the box?
> It seems to be an easy one...
>
> At least this way it will not error out if someone selects it...
You only get an error if you mismatch the CMake settings to the the
HI Vagn,
The OSG has built in support for multi-view and stereo, there should
be no need to attempt to play games with rendering with two separate
osgviewer instances.
Since you are describing a set up there I've never come across anyone
attempting before could you take a step back and explain
Hi Tim,
I just don't understand why Texture2D isn't sufficient for everything
you are doing. glTextureRectangle is deprecated, it was a temporary
workaround added to OpenGL, you shouldn't need it at all now that
OpenGL fully support non power of two textures.
So please just use Texture2D all
Hi Werner,
What are you using the ABSOLUTE_RF Camera's for? My guess this is the
source of the problems, perhaps the approach you've take with this
works fine for a single viewport but breaks any form of
multi-viewport/window composition of the view.
Could you explain what the ABSOLUTE_RF
Hi Tim.
Texture2D and TextureRectangle are wrappers around two distinct types
of OpenGL textures, and at a C++ level are both subclassed from
osg::Texture, so there is no OpenGL level mapping that makes sense in
attempting to convert one to the other, and at the C++ level there
isn't any means
HI Werner,
It sounds like you are trying to resolve a problem at the low level
which you have created by setting things up incorrectly and the top
level.
So.. what you need to do is change how you are configuring things at
the top level. You don't clearly explain what task you are trying to
On Mon, 25 Jun 2018 at 10:45, michael kapelko wrote:
> Any particular reason for running the whole day? (Was that requirement
> somewhere in Vulkan end-user agreement? :P)
Didn't think about work for a second :-)
I just love trail running, and covering the 95 miles of the West
Highland Way long
Hi Dan,
On Mon, 25 Jun 2018 at 10:37, Daniel Emminizer, Code 5773
wrote:
> I’ve built and have been running OSG 3.6.2-rc1 on several MSVC versions and
> g++ 4.4 without problems since Wednesday. Success all around so far.
Thanks for the testing and feedback, good to hear it's working OK.
On Mon, 25 Jun 2018 at 09:30, Jorge Izquierdo Ciges wrote:
> It is a little bit sad to lose the Open part of the name, why not go for Open
> Vulkan Scene Graph or Open Scene Graph: Vulkan
>
> (The second works better as a serialized book title :P )
"Open Vulkan Scene Graph" doesn't avoid the
Hi Maxim.
On Sat, 23 Jun 2018 at 18:19, Maxim Stere wrote:
> 1) I've been playing around with GL3 and CORE profiles on windows, and
> noticed that for CORE, the CMake script makes VS look for GL/glcorearb.h and
> for GL3 profile it makes VS look for GL3/gl3.h neither of which are present
> on
Hi Tyler,
Modern graphics cards love coarse grained chunks of static geometry,
they can churn through at millions of vertices a second without
breaking sweat.
Once you start make the scene graph more fine grained or making more
of the geometry dynamic so that it has to be updated per frame then
On Sat, 23 Jun 2018 at 22:31, Terry Welsh wrote:
> Is it worth asking if this project will be a scene graph or a
> rendering engine?
It'll be a rendering+compute API based Vulkan that represent the Scene
as a Graph. VulkanSceneGraph tells people exactly what it is,
anything else moves away
On Sat, 23 Jun 2018 at 11:13, Tim Moore wrote:
> Just call it VSG!
That's the planned namespace :-)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Hi All,
When not coding and running around after my family I like to go
running, and to maximize the amount of fun that can be had running why
not do it all day!! :-)
My race starts at 1am Saturday on the west side of Glasgow, follows
the West Highland Way, and finishes 95 miles (152km) later in
HI Bret,
As long as adding support does introduce problems with other usage
case I see no reason not to merge a patch adding palette support. My
guess is that you'll need to resole the palette into a full osg::Image
with RGB(A) within the plugin, as osg::Image doesn't have palette
support (and
On Fri, 22 Jun 2018 at 00:55, Maurizio Vitale wrote:
> well the case of Apple (computer) vs Apple (the music company) was very
> similar: a common word and very different industries (at the time Apple was
> not in the music/multimedia industry).
Khronos, a standards body, and an open source
A short note on "The importance of working in a isolation."
This thread has been ended straying away from what I intended. It was
announcement, and never intended to a discussion or technical issues
or wish-lists, personal preferences, from the community. It's
devolved a bit into this as I
On Thu, 21 Jun 2018 at 17:25, Scott Bailey wrote:
> Regarding smart pointers, Boost Libs has a mature implementation that
> includes intrusive_ptr<>. Adding another dependency is, of course, a mixed
> bag; however, if you go header only with boost libs it's reasonable.
>
> For my projects, I
401 - 500 of 12708 matches
Mail list logo
