Frustrum frustration

Replies to This Discussion

Permalink Reply by David Rutten on September 19, 2012 at 2:32am

You want a plane that is perpendicular to the camera and whose Y-axis is parallel with the camera up vector?

If yes, I think you want to use the GetFrustumNearPlane() method.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Adam Chałupski on September 23, 2012 at 11:24pm

Thank You ! Yes, that is what i need  ! 

But using:

Public Function GetFrustumNearPlane (A ByRef plane As Plane) As Boolean

I got following error:

Error: Statement cannot appear within a method body. End of method assumed. (line 90)
Error: Comma or ')' expected. (line 90)
Warning: Function 'GetFrustumNearPlane' doesn't return a value on all code paths. Are you missing a 'Return' statement? (line 91)

Permalink Reply by David Rutten on September 24, 2012 at 12:16am

You're not supposed to write the function, we already did that. You're supposed to use it.

Dim plane As Plane

If (....GetFrustumNearPlane(plane)) Then

   'hoorah!

Else

  'boo

End If

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Adam Chałupski on September 24, 2012 at 4:03am

I got a desired Plane by using:
Dim plane As Plane
RhinoDoc.ActiveDoc.Views.ActiveView.MainViewport.Getfrustumnearplane(plane)
A = plane

I need that Plane to change dynamically whenever camera position is changed. How to do that - should i use if/else statement (how?) or loop it, so plan would be updated every single "time unit" ?

Permalink Reply by David Rutten on September 24, 2012 at 5:10am

If you want to draw your own geometry in the viewport then you should handle drawing events. Then you can get the proper frustum data every time you are asked to draw something and you can draw it perpendicular to the camera.

Generating geometry inside Grasshopper and updating the solution to generate new geometry every time a viewport redraws is a really bad idea. Are you using Display conduits to draw your own stuff or are you outputting geometry in a component?

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Adam Chałupski on September 24, 2012 at 8:35pm

Hi David,

All I want is dynamic plane, perpendicular to camera with Y-axis parallel to camera up vector on the output of GH component.  I read on GH and Rhino forum that this is not as easy as making other kind of planes because I need to deal with Display Pipline .

There's a few threads about similar problem( i'm posting them here as a reference) 

1. Viewport rectangle

2. TextTag parallel to Viewport

3. Horster method (with timer)

4. Another horster method to get On screen display (also with timer)

5. Discussion how to send Rhino Viewport Cplane to GH

There is a lot of things possible to do using camera frustum plane such as:

- making custom project layout

- Camera-plane sections

- 3d Isovist (example of Francois)

- projections on the frustum plane

I need to output geometry to Grasshopper in order to use a Frustum Plane for dynamic operations like for example: On Screen Display of Text Tags with sections and other views.

Permalink Reply by David Rutten on September 25, 2012 at 5:33am

Apart from potential racing conditions you'll also sacrifice viewport performance. If every viewport redraw triggers a Grasshopper solution (which will in turn trigger a viewport redraw, hence the race condition trap) then you will never be able to have smooth viewport navigation.

There's another problem to do with clipping. Basically the frustum is calculated based on the  boundingbox of the geometry that each viewport has to display. When you start adding geometry to the edges of this boundingbox, you'll grow the frustum on every redraw.

I tried to circumvent these problems in the attached file, but I remain of the opinion that using view direction to control data is a bad idea.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Attachments:

• FrustumUpdate.gh, 2 KB

Permalink Reply by Adam Chałupski on September 26, 2012 at 7:14pm

Thank You David so much for that script. I've been trying to run it but its dedicated to newer versionGH.90013 while i'm using GH.90012

Beside all the problems you've mentioned I want to know one thing and then my frustrum frustration will be gone. Why are dynamic camera components so dificult to send to GH when on rhino viewport you can switch Show Camera and see all camera components as points. They are fully editable, behave as points and camera viewport always smoothly follows any changes of them position. And vice versa - when you rotate or pan camera viewport then you can see them moving on another viewports. If they have X,Y,Z and proper ID, then would it be possible to introduce them to GH component ?

Permalink Reply by David Rutten on September 27, 2012 at 8:39am

Apart from the opening warning it should still load I think.

Rhino camera objects are part of core Rhino. All the information regarding the positions and directions of each viewport camera are known and whoever wrote the camera implementation had full access to all of Rhino code. Though even there you will notice that when cameras are enabled, Rhino viewports are somewhat slower then without them. All this extra redrawing takes its toll.

Even so, there will be thousands of lines of code involved in getting the Rhino cameras to work the way they do. When you use Rhino commands you get this code for free, that is why it is easy.

Another thing is that Rhino cameras are viewport specific objects. The camera geometry is only visible in the other viewports, not the target viewport. Grasshopper has no mechanism for excluding certain viewports for certain kinds of preview.

 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Tiara Jacinta on September 1, 2015 at 1:26am

Can I be a pain and ask if you guys know of a way of making the point shown in the first image, and the second point shown in the second image and make them adjustable in Grasshopper, not just dependent on the view portal that the user is looking through?