GT relation to GR : Custom geometry display

[nicholas_yue]

Hi,

 

  I am starting to learn about writing a custom geometry display.

 

  I started looking at the tetprim example.

 

  I have read about GR_* code in the past and also previous post on odforce.net

 

  I have only recently discover GT_* whilst looking at the tetprim.

 

  Is there an overview as to the relationship between GR and GT ? Is GT something recent ? I am guessing it is related to tessellation. Is it optional ?

 

Cheers

[Guest mantragora]

EDIT: I stripped on pieces this example around 1 year ago, but I don't remember anything from it today. Sorry for spamming

Edited December 7, 2014 by mantragora

[malexander]

You don't need to use GT at all, you can still write a render hook on a GEO_Primitive. GT is a light abstraction layer that allows geometry to come from GU, or directly from Alembic. It also does such useful things as:

• Collection of all primitives of a certain type to batch them together for faster drawing.
• Modification of the geometry for display without touching the original GU_Detail (polygon convexing and triangulation, adding point normals when normals don't exist, color overrides for visualization, etc)
• Creation of completely new geometry not based on GU_Detail, such as for guides.
• Refinement of complex primitive types into simpler ones (ie a NURBS surface into polygon mesh, via tessellation)

There is also some primitive-type specific stuff in GT, such as the deformation and LOD handling of agents.

[nicholas_yue]

You don't need to use GT at all, you can still write a render hook on a GEO_Primitive. GT is a light abstraction layer that allows geometry to come from GU, or directly from Alembic. It also does such useful things as:

• Collection of all primitives of a certain type to batch them together for faster drawing.
• Modification of the geometry for display without touching the original GU_Detail (polygon convexing and triangulation, adding point normals when normals don't exist, color overrides for visualization, etc)
• Creation of completely new geometry not based on GU_Detail, such as for guides.
• Refinement of complex primitive types into simpler ones (ie a NURBS surface into polygon mesh, via tessellation)

There is also some primitive-type specific stuff in GT, such as the deformation and LOD handling of agents.

[nicholas_yue]

I wish to display a frustum like object associated with a camera.

 

Looking at the tetraprim example and knowledge that GT is optional, I am down to the minimal required classes as

 

SOP_Frustum, GU_Frustum, GR_Frustum and GEO_Frustum which I need to implement, to draw a 6 side box.

 

If I am not interested in the SOP being renderable (i.e. in Mantra etc) as it is for feedback to the artists. Are all the G* subclasses still required or is one able to simply implement and register a draw hook in SOP_Frustum ?

 

Cheers

[Guest mantragora]

If it doesn't have to be renderable, maybe you want only draw something in viewport that is not a part of main GDP. Have you tried to look into DM and/or GUI renderhooks? Or if we are in SOP feedback, cookMyGuide1 and cookMyGuide2 methods for drawing guide geometry?

[nicholas_yue]

If it doesn't have to be renderable, maybe you want only draw something in viewport that is not a part of main GDP. Have you tried to look into DM and/or GUI renderhooks? Or if we are in SOP feedback, cookMyGuide1 and cookMyGuide2 methods for drawing guide geometry?

I had a look at the GUI example GUI_PolySoupBox.C but I think that is not suitable for my needs. GUI_* seems to be global toggle (at least in the example). I want the frustum display only for specific camera I am connecting/associating with, rather than all the cameras in a scene.

 

I think DM_* is the way to go for now.

 

Is there an example of registering DM_* hook directly in a SOP or must it be via GDP+GU_* code ?

 

Cheers

[Guest mantragora]

I had a look at the GUI example GUI_PolySoupBox.C but I think that is not suitable for my needs. GUI_* seems to be global toggle (at least in the example). I want the frustum display only for specific camera I am connecting/associating with, rather than all the cameras in a scene.

You can turn it on silently:

As for SOPs, there is no solid connection between the viewport and a SOP except for the main GU_Detail it produces and its guide GU_Details (see SOP_Node.h). However, you could add a private detail attribute such as "_poly_face_hook_enable_" and only instantiate your GR_Primitive if this is found in the GU_Detail that is being refined (check for this attrib in your GUI_PrimitiveHook::createPrimitive). The private detail attribute won't be visible, nor will it be copied to the SOP's outputs.

This topic may be interesting for you =>

https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=29374&postdays=0&postorder=asc&start=25&sid=8f2bc6680d7e5bc50491fce814ab8476

 

I think DM_* is the way to go for now.

 

Is there an example of registering DM_* hook directly in a SOP or must it be via GDP+GU_* code ?

 

Cheers

It's not a problem to get windows, but I have not tried to use just SOP to render anything directly. To be fair I'm not even sure that it would be save to do that. I think it would be better to keep Hook and SOP as separate parts, this way your SOP will work no matter what.

I think the easiest way would be to just write DM SceneHook just like the Bible says . Just turn it on in the same, hidden way like @twod aka @malexander mentions. Make some public data in SOP that your Hook will access and I think you should be good to go. Boom!

Edited December 8, 2014 by mantragora