[vtk-developers] Merging of new rendering branch to VTK

Marcus D. Hanwell marcus.hanwell at kitware.com
Mon Jun 23 10:02:56 EDT 2014


John,

I am sure you will get tired of me telling you once we have everything
working ;-) We have made major changes to how VTK's mappers render
polygonal data, going from an immediate mode where many things were
iterated over on a per-vertex/per attribute level (with optional
display lists) to a batch-based model based upon modern rendering
paradigms. More concretely we now convert polygonal data to graphical
primitives ready to be uploaded to GPU RAM in tight loops without
going through several levels of virtual functions, and then upload in
one call. We have moved from the use of the fixed pipeline to a
shader-based rendering pipeline, and have achieved significant
speedups for several typical rendering workloads.

Going forward, by using a common subset of API from OpenGL 2.1 and ES
2.0 we are working on sharing more rendering code between embedded and
desktop. There are less side effects due to a significantly reduced
state machine in modern OpenGL, but there are also some challenges we
are working on with regards to rendering of cell based topology. I am
excited to get things in shape for building things like ParaView on
top of this too, and there are several new features we are working on.

I will continue fixing stuff up with the existing renderer, and we
will add more dashboards for this backend shortly.

Thanks,

Marcus

On Fri, Jun 20, 2014 at 3:13 PM, Biddiscombe, John A. <biddisco at cscs.ch> wrote:
> Marcus,
>
> OK. Understood. I guess the question I really wanted to ask would be …
>
> What have you changed that makes things better? What will I want from the
> new rendering framework?
>
> Thanks
>
> JB
>
> On 20/06/14 16:59, "Marcus D. Hanwell" <marcus.hanwell at kitware.com> wrote:
>
>>Hi John,
>>
>>The default will remain the existing painters/mappers and you can
>>continue to use them. I will work on adding documentation but it is
>>sparse at this stage. What I merged is a first-pass implementation
>>where I am sure further changes will be necessary (we know of several
>>missing features). At the high level they do not use/implement any of
>>the painter API, but the painter API in Rendering/Core remains
>>untouched - we do not intend to add the painter API to these mappers.
>>They implement many of the classes in Rendering/Core, and use the same
>>object factory override mechanism. You could port the mapper API you
>>need into your own custom mapper, and even look at remote modules that
>>we will work on adding soon.
>>
>>We have not addressed extension of the mappers, and so it would be
>>premature to attempt it. We will get to that, and part of the
>>motivation of merging this branch is to start merging more frequently
>>and benefit from wider testing. I will be working towards getting
>>ParaView to build against the new rendering backend, but that is not
>>yet possible as several of the rendering modules it uses have hard
>>dependencies on the existing Rendering/OpenGL module.
>>
>>I hope that makes things a little clearer, and I will work on adding
>>some documentation as things stabilize. The way in which we render
>>most geometry has changed in quite significant ways in order to take
>>advantage of modern OpenGL APIs in efficient ways
>>
>>Thanks,
>>
>>Marcus
>>
>>On Fri, Jun 20, 2014 at 8:05 AM, Biddiscombe, John A. <biddisco at cscs.ch>
>>wrote:
>>> Marcus,
>>>
>>> I've got quite a lot of custom rendering modules and would like to add
>>>some extra cuda render passes to my paraview representations - are the
>>>changes you are making/have made to the vtk rendering documented
>>>anywhere so I can see what impact this will/does have on existing
>>>painters/mappers etc?
>>>
>>> thanks
>>>
>>> JB
>>>
>>> -----Original Message-----
>>> From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf
>>>Of Marcus D. Hanwell
>>> Sent: 20 June 2014 05:38
>>> To: VTK Developers
>>> Subject: [vtk-developers] Merging of new rendering branch to VTK
>>>
>>> Hi,
>>>
>>> We have been hard at work on new rendering code for VTK that makes use
>>>of OpenGL 2.1+, and moves to modernize our rendering code. We have also
>>>added new CMake capabilities to specify a rendering backend, this
>>>defaults to the existing rendering code but can be swapped out for the
>>>new. This has been in development for several months, and we intend to
>>>merge it to master tomorrow.
>>>
>>> If you want to build the new rendering modules they are mutually
>>>exclusive of the old rendering modules, as it was necessary to reuse the
>>>same class names etc. They depend upon GLEW and Eigen at this time, and
>>>I have not yet done the work to add either as third party modules (I
>>>will get to it). We will be adding several dashboards to test the new
>>>rendering backend next week.
>>>
>>> I intend to merge the main branch tomorrow, and will monitor the
>>>dashboard for issues over the weekend (using the existing OpenGL
>>>implementation). Next week we will add dashboard submissions testing the
>>>new rendering backend. We will then attempt to merge updates to this new
>>>rendering code more regularly. There are some pretty significant
>>>rendering improvements, and we will summarize these in the coming weeks
>>>too.
>>>
>>> Hopefully disruption to master will be minimal, please let me know if
>>>you think there is anything I missed. I am really excited to get some of
>>>this code to a wider group, and hope to begin showcasing some of the
>>>progress we have made.
>>>
>>> Thanks,
>>>
>>> Marcus
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>>http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>
>



More information about the vtk-developers mailing list