Re: [osg-users] Thoughts on Vulkan

[Rafa Gaitan]

Hi,

Additionally to the book you can find very good tutorials and references
here: https://vulkan-tutorial.com/

Robert, I'm quite interested and I'll be glad to help in the development of
the new scenegraph :). I have some ideas for the new library regarding the
similarities between Vulkan and OpenCL which might be interesting to study.

Chris, is there any public repository where we can take a look to
Heirograph? ;)

Best regards,
Rafa.


El mar., 14 feb. 2017 a las 17:13, Chris Hanson ()
escribió:

> I just wanted to mention that Jeremy ("osgWidget", "osgCairo", "osgPango")
> has been working on a scene graph named Heirograph with similar design
> goals. There is already an OpenGL ES2 backend implementation and our goal
> is, similar to Robert's, to make a Vulkan and a desktop non-FFP OGL3+ or
> OGL4 backend as well.
>
> It is based on modern C++11 and has a basic model loader based on Assimp.
>
> It can even already render some things. ;)
>
> There is no OSG-to-Heirograph loader/converter (yet), but Paul Martz
> already did one of those with his earlier "JAG" OSG3+ scenegraph project,
> so it wouldn't be difficult.
> ___
> 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] Thoughts on Vulkan

[Chris Hanson]

I just wanted to mention that Jeremy ("osgWidget", "osgCairo", "osgPango")
has been working on a scene graph named Heirograph with similar design
goals. There is already an OpenGL ES2 backend implementation and our goal
is, similar to Robert's, to make a Vulkan and a desktop non-FFP OGL3+ or
OGL4 backend as well.

It is based on modern C++11 and has a basic model loader based on Assimp.

It can even already render some things. ;)

There is no OSG-to-Heirograph loader/converter (yet), but Paul Martz
already did one of those with his earlier "JAG" OSG3+ scenegraph project,
so it wouldn't be difficult.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Thoughts on Vulkan

[Chris Hanson]

​There aren't many sources, to be honest.

If you like dead-tree type material, I was tech reviewer on this book:
https://www.amazon.com/Vulkan-Programming-Guide-Official-Learning/dp/0134464540


It has good material, but the scope of the task is daunting no matter how
you approach it.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Thoughts on Vulkan

[sam]

Hi Guys,

Sorry to hijack this thread a little bit. What would you guys consider the
best source of information for Vulkan? Primarily focusing on the
fundamentals.

Thanks, Sam

On Mon, Feb 13, 2017 at 5:43 AM, Robert Osfield 
wrote:

> On 13 February 2017 at 12:17, Nickolai Medvedev 
> wrote:
> > So, Robert, if you if you are going to use C++11, it means that
> > OpenThreads won't be used anymore(use std::thread)?
>
> One of the reasons to use C++11 is avoid the need to external
> dependencies such as OpenThreads.
>
> However, C++11 threading is still a bit too primitive for serious
> threading work as there is no support for processor affinity so we'd
> need to implement this.
>
> 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] Thoughts on Vulkan

[Robert Osfield]

On 13 February 2017 at 12:17, Nickolai Medvedev  wrote:
> So, Robert, if you if you are going to use C++11, it means that
> OpenThreads won't be used anymore(use std::thread)?

One of the reasons to use C++11 is avoid the need to external
dependencies such as OpenThreads.

However, C++11 threading is still a bit too primitive for serious
threading work as there is no support for processor affinity so we'd
need to implement this.

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

Re: [osg-users] Thoughts on Vulkan

[Robert Osfield]

On 13 February 2017 at 12:13, Nickolai Medvedev  wrote:
> And it is good that you have ideas.
> First of all, it is necessary to refuse opengl fixed pipeline.

I don't understand your use of "refuse" here?

For OSG-3.6 my plan is to attempt to have an automatic mapping of old
fixed function pipeline state to shader based state.

> It is necessary to create shader-based lighting system.

That all depends upon your needs and the scene graphs you are using,
this applies to the OSG or any other scene graph.

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

Re: [osg-users] Thoughts on Vulkan

[Nickolai Medvedev]

So, Robert, if you if you are going to use C++11, it means that
OpenThreads won't be used anymore(use std::thread)?

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





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

Re: [osg-users] Thoughts on Vulkan

[Nickolai Medvedev]

Hi, Robert.

And it is good that you have ideas.
First of all, it is necessary to refuse opengl fixed pipeline.
It is necessary to create shader-based lighting system.
I already try to create deferred rendering with various models of lighting
(phong, cook-torrance, etc.), but now it isn't a lot of time, therefore
work has stopped.

Cheers,
Nickolai

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





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

Re: [osg-users] Thoughts on Vulkan

[Robert Osfield]

On 12 February 2017 at 22:22, Nickolai Medvedev  wrote:
> Transition to Vulkan will be difficult. Partly because, that all graphics is
> based on shaders. But I think that the new system for OpenSceneGraph - it is 
> good.
> I will try to help, as far as I will be able.

I've have been putting several ideas that I developed for the new
scene graph into the OSG, this will be in 3.6;-)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Thoughts on Vulkan

[Nickolai Medvedev]

Hi, Robert.

Transition to Vulkan will be difficult. Partly because, that all graphics is 
based on shaders. But I think that the new system for OpenSceneGraph - it is 
good.
I will try to help, as far as I will be able.

Cheers,
Nickolai

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





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

Re: [osg-users] Thoughts on Vulkan

[sduclos]

wow, serious fun!

thxs for the road map

On 2/11/17, Robert Osfield  wrote:
> On 11 February 2017 at 16:56, sduclos  wrote:
>> Perhaps using Vulkan as a backend to OpenGL ES2 (ex.: ANGLE)
>> would not be as involving as rewriting OSG (outch!)
>
> Vulkan is very different to OpenGL/OpenGL ES.  To make the most of
> Vulkan, to give all the flexibility and performance benefits you need
> to build the scene graph with this in mind.
>
> The OSG just can't deliver this, it's an OpenGL scene graph by design,
> it works with and around OpenGL capabilities/limitations.  If you
> attempted to graft Vulkan support you'd have to limit the
> implementation, if you attempted to use a Vulkan backend hidden by a
> OpenGL/ES layer on top of Vulkan you'd loose the benefit of Vulkan,
> you'd be better off just using the OpenGL or OpenGL driver directly.
>
> I think it's crucial to grasp that Vulkan is VERY different to
> OpenGL/ES.  The threading and performance differences in Vulkan will
> change the way we go about implementing graphics.  For instance right
> now the API overhead in OpenGL/ES is so high we have to do lots to
> work batching graphics operations to get best performance. hiding the
> API overhead.  We also are forced to dispatch data into the OpenGL/ES
> fifo single threaded.  For a scene graph to make the most of the new
> capabilities you have to be able thread preparation of the graphics
> data, and now that the API overhead is reduced we open the door to
> doing less batching and returning to a more fine grained scene graph
> in memory that better maps to what is convenient to implement for the
> graphics application rather than try to workaround them doing batching
> even when it hurts other parts of our application development.  With a
> potentially fine grained scene graph we also need to avoid CPU
> overheads associated with that scene graph, otherwise will put a
> performance bottleneck in the application that prevents us seeing all
> the potential of the graphics hardware.
>
> We simple can't achieve the full potential by grafting Vulkan into/or
> adapting it.  We have to understand Vulkan and build around it,
>
> Another consideration is that C++ has moved on, a new scene graph can
> adopt C++11, 14, 17, which due to backwards compatibility issues the
> OSG can't adopt these recent versions of C++. Perhaps it 5 years it
> might be able to do, but not right now if we want to carry the
> majority of the community with us.
>
> 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] Thoughts on Vulkan

[Robert Osfield]

On 11 February 2017 at 16:56, sduclos  wrote:
> Perhaps using Vulkan as a backend to OpenGL ES2 (ex.: ANGLE)
> would not be as involving as rewriting OSG (outch!)

Vulkan is very different to OpenGL/OpenGL ES.  To make the most of
Vulkan, to give all the flexibility and performance benefits you need
to build the scene graph with this in mind.

The OSG just can't deliver this, it's an OpenGL scene graph by design,
it works with and around OpenGL capabilities/limitations.  If you
attempted to graft Vulkan support you'd have to limit the
implementation, if you attempted to use a Vulkan backend hidden by a
OpenGL/ES layer on top of Vulkan you'd loose the benefit of Vulkan,
you'd be better off just using the OpenGL or OpenGL driver directly.

I think it's crucial to grasp that Vulkan is VERY different to
OpenGL/ES.  The threading and performance differences in Vulkan will
change the way we go about implementing graphics.  For instance right
now the API overhead in OpenGL/ES is so high we have to do lots to
work batching graphics operations to get best performance. hiding the
API overhead.  We also are forced to dispatch data into the OpenGL/ES
fifo single threaded.  For a scene graph to make the most of the new
capabilities you have to be able thread preparation of the graphics
data, and now that the API overhead is reduced we open the door to
doing less batching and returning to a more fine grained scene graph
in memory that better maps to what is convenient to implement for the
graphics application rather than try to workaround them doing batching
even when it hurts other parts of our application development.  With a
potentially fine grained scene graph we also need to avoid CPU
overheads associated with that scene graph, otherwise will put a
performance bottleneck in the application that prevents us seeing all
the potential of the graphics hardware.

We simple can't achieve the full potential by grafting Vulkan into/or
adapting it.  We have to understand Vulkan and build around it,

Another consideration is that C++ has moved on, a new scene graph can
adopt C++11, 14, 17, which due to backwards compatibility issues the
OSG can't adopt these recent versions of C++. Perhaps it 5 years it
might be able to do, but not right now if we want to carry the
majority of the community with us.

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

Re: [osg-users] Thoughts on Vulkan

[Robert Osfield]

On 11 February 2017 at 12:15, Max Maslov  wrote:
> Thanks for answer. So, when you plan to start developing of Vulkan scene 
> graph? Maybe after 3.6?  :)

My plan is complete the OSG-3.6 stable release and then move to the
new scene graph.

My intention is for the core of the new scene graph to be API
agnostic, then have backends for Vulkan,  OpenGL and OpenGL ES.

The focus will be primarily on Vulkan in terms of making sure the
design of the scene graph fully leverage what Vulkan is capable of.
Until we get an implementation going I can't say exactly how this will
impact the OpenGL/ES side.  The new scene graph needs to be relevant
to application developers for the next 15+ years, taking over the
"mantel" from the OSG is this respect ;-)

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

Re: [osg-users] Thoughts on Vulkan

[sduclos]

Hi Robert,

Perhaps using Vulkan as a backend to OpenGL ES2 (ex.: ANGLE)
would not be as involving as rewriting OSG (outch!)

Sylvain.


On 2/11/17, Robert Osfield  wrote:
> On 11 February 2017 at 08:29, Max Maslov  wrote:
>> Any news about Vulkan in OSG?
>
> I continue to believe it is impractical to support Vulkan directly
> within the OSG, while technical possible it would require a massive
> rewrite which would break backwards compatibility and require major
> changes to OSG applications.
>
> The path I am planning to develop a another scene graph that directly
> supports Vulkan, and have support for integrating the OSG and this new
> scene graph.  The intention behind this would be to make it possible
> for OSG applications to be migrated across incrementally as well as
> provide a leg up to the new scene graph by giving it access to OSG
> loaders etc.
>
> 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] Thoughts on Vulkan

[Max Maslov]

Thanks for answer. So, when you plan to start developing of Vulkan scene graph? 
Maybe after 3.6?  :)

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





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

Re: [osg-users] Thoughts on Vulkan

[Robert Osfield]

On 11 February 2017 at 08:29, Max Maslov  wrote:
> Any news about Vulkan in OSG?

I continue to believe it is impractical to support Vulkan directly
within the OSG, while technical possible it would require a massive
rewrite which would break backwards compatibility and require major
changes to OSG applications.

The path I am planning to develop a another scene graph that directly
supports Vulkan, and have support for integrating the OSG and this new
scene graph.  The intention behind this would be to make it possible
for OSG applications to be migrated across incrementally as well as
provide a leg up to the new scene graph by giving it access to OSG
loaders etc.

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

Re: [osg-users] Thoughts on Vulkan

[Max Maslov]

Any news about Vulkan in OSG?

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





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

Re: [osg-users] Thoughts on Vulkan

[Cor Jansen]

robertosfield wrote:
> 
> 
> This is not far from my own viewpoint.  I do have a rough plan in mind that 
> is still evolving. I'll open my own thoughts for discussion once OSG-3.4 is 
> out the door.
> 
> 


What is the status of this white paper?
I really would like to discus this.

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





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

Re: [osg-users] Thoughts on Vulkan

[Robert Osfield]

On 29 December 2015 at 23:30, Cor Jansen  wrote:
> What is the status of this white paper?

Afraid I've been too busy with client work to write it yet.

> I really would like to discus this.

As a spare time activity I've begun design work exploring what a next
gen scene graph that supports multiple graphics APIs that would
include OpenGL/GLES and Vulkan.  I have many sheets of white paper
with writing and diagrams on but none of it is in a form that can be
published and when I get a time slot I'll dive in a start
experimenting with the implementation side.

The general gist is I don't believe the OSG itself can be morphed to
support a radically new API like Vulkan without massively breaking the
existing OSG API.  We either retain the bulk of the existing OSG API,
stay focused on OpenGL/GLES and retain our existing user base or we
break the API in extensive ways to support Vulkan and accept that we
won't carry the majority of the existing community with us.

In my design work on a next gen scene graph I have sought ways of
making it compatible with existing OSG applications so users could bit
by bit move across when they feel the need.  In you'd want to move
across to Vulkan and still use the OSG one would need to replace
extensive parts of the OSG scene graph across to the next gen scene
graph. It may be even appropriate at some point to enable a build of
the OSG that doesn't have any OpenGL calls, so that the whole
GL/Vulkan calls are deferred to the next gen scene graph.

Exactly what this next gen scene graph would look like and the exact
mechanics of integration of the OSG is not something I can say yet -
original designs very often don't survive implementation.  For the OSG
community though I have the intention to try and make this integration
possible.  My clients are all OSG users so there is plenty of
motivation for me to make sure this path works out as well.  So I
won't be turning my back on the OSG and it's community.

I can't really say too much more at this point.  Vulkan hasn't been
released yet.  I haven't begun implementing the next gen scene graph
that wafting around my head and on bits of paper.  The only big
decisions I've made so far is that a new scene graph would be written
in C++11, use it's threading etc, support multiple graphics APIs and
be possible to integrate it with OSG and other applications and will
be open source.

When concrete progress happens I will keep the OSG community involved.

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

Re: [osg-users] Thoughts on Vulkan

[Robert Osfield]

Hi David, Chris et. al,

On 14 April 2015 at 22:47, Chris Hanson xe...@alphapixel.com wrote:

 I think OSG is a bad fit for Vulkan. OSG has so much code to support FFP
 dataflows that Vulkan doesn't have.

 I personally think a Vulkan scenegraph could be made from the components
 of OSG (OSG 4.x?) but bringing along all of OSG's legacy code into a Vulkan
 space would be counterproductive.


This is not far from my own viewpoint.  I do have a rough plan in mind that
is still evolving. I'll open my own thoughts for discussion once OSG-3.4 is
out the door.

Right now getting a OSG-3.4 is my focus.

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

Re: [osg-users] Thoughts on Vulkan

[Chris Hanson]

I think OSG is a bad fit for Vulkan. OSG has so much code to support FFP
dataflows that Vulkan doesn't have.

I personally think a Vulkan scenegraph could be made from the components of
OSG (OSG 4.x?) but bringing along all of OSG's legacy code into a Vulkan
space would be counterproductive.
​
As far a stability of Vulkan, you are correct, it will have rough edges.
But it's being built on the designs of Metal and Mantle and those already
have a pretty good track record. And part of the point of Vulkan is to make
a much smaller footprint, so driver stability is much easier to achieve.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Thoughts on Vulkan

[David Glenn]

Well Chris, I don't think that anyone has ruled out using Vulkan on OSG, it 
just that the verdict is out about adoption. Besides, as I have learned from my 
resent VR experience, sometimes early adoption is not the wise course of 
action. 

As for me, I will adopt Vulkan when I have a good understanding of how it works 
and the standards are stable. It took awhile before the standards for GLSL to 
be ironed out. I'm worried about it being the same way for Vulkan.   

D Glenn


Chris Hanson wrote:
 Personally, my thought on Vulkan is that it present an opportunity to solve a 
 number of long-standing problems that history has shown OpenGL now has as a 
 result of graphics software and hardware evolving.
 
 
 OpenGL was intended as standardized moderately high-level abstraction layer. 
 Today, applications want to be able to choose and customize their high level 
 abstraction (which is what scene graphs like OSG and game engines like Unity 
 are) and those engines want a lower-level  of the actual hardware. Vulkan 
 seeks to address this change.
 
 
 
 -- 
 Chris 'Xenon' Hanson, omo sanza lettere.  http://www.alphapixel.com/ 
 (http://www.alphapixel.com/)
 Training • Consulting • Contracting
 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • 
 GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
 Legal/IP • Code Forensics • Digital Imaging • GIS • GPS • osgEarth • Terrain 
 • Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • 
 Android
 @alphapixel (https://twitter.com/alphapixel) facebook.com/alphapixel 
 (http://facebook.com/alphapixel) (775) 623-PIXL [7495]
 
  --
 Post generated by Mail2Forum



David Glenn
---
D Glenn 3D Computer Graphics Entertainment.
www.dglenn.com

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





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

Re: [osg-users] Thoughts on Vulkan

[Chris Hanson]

Personally, my thought on Vulkan is that it present an opportunity to solve
a number of long-standing problems that history has shown OpenGL now has as
a result of graphics software and hardware evolving.

OpenGL was intended as standardized moderately high-level abstraction
layer. Today, applications want to be able to choose and customize their
high level abstraction (which is what scene graphs like OSG and game
engines like Unity are) and those engines want a lower-level  of the actual
hardware. Vulkan seeks to address this change.



-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Code Forensics • Digital Imaging • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel https://twitter.com/alphapixel facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Thoughts on Vulkan

[David Glenn]

Greetings!

Neil Trevett has made it clear that OpenGL is in its prime and not going away, 
so I'm not rushing to buy my Vulkan red book just yet - like there is any! 

I see Vulkan as something that is geared to a gaming engines for the short 
term! Over time, who knows! Valve, Unity and Epic are going to be the early 
adopters from what I understand. I will see how that goes as I'm in the middle 
of researching VR for Simulation, raping my brain around the Time Warp function 
and taking notes!

D Glenn


David Glenn
---
D Glenn 3D Computer Graphics Entertainment.
www.dglenn.com

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





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

Re: [osg-users] Thoughts on Vulkan

[Robert Osfield]

On 16 March 2015 at 04:36, Chris Hanson xe...@alphapixel.com wrote:

 I'd be interested in seeing a draft of your white paper if you're willing
 to share.


I'm not far enough along with the writing it all down to share yet.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Thoughts on Vulkan

[Preet]

Hey all,

Now that the Khronos group has announced Vulkan/SPIR-V, are there any plans
to integrate it into OSG as an alternative back end?


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

Re: [osg-users] Thoughts on Vulkan

[Chris Hanson]

I've been kind of looking at it and not thinking it's a very good fit.
We've been writing a couple of new minimal scene graphs for the non-FFP
future (JAG, and another called Sobek), and are wondering if it makes sense
to rewrite one of those to Vulkan and then just try to port the desirable
things forward from OSG as they are needed.

OSG is big and has lots of interesting things, but OSG is also big and has
lots of _interesting_ things...

On Sun, Mar 15, 2015 at 9:48 AM, Preet prismatic.proj...@gmail.com wrote:

 Hey all,

 Now that the Khronos group has announced Vulkan/SPIR-V, are there any
 plans to integrate it into OSG as an alternative back end?


 Preet

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




-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Code Forensics • Digital Imaging • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel https://twitter.com/alphapixel facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org