Jump to content
Sign in to follow this  
nicholas_yue

GT relation to GR : Custom geometry display

Recommended Posts

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

Share this post


Link to post
Share on other sites
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 by mantragora

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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?

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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 by mantragora

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×