ok but seriously, who needs 10 k of people facing you in real time, or how many face me objects does one need? should maybe become a rockstar instead of a cad designer!!! but even then whats the big problem, in those rare out of space cases our muscle computers should snap that like a huge bulldozer moving a piece of sand cake in a sand box. if you have 10.000 face me objects with different images of super high resolution then i actually would suggest to see a doctor for the first time
I guess i should change models to ppl then in this beta showoff image (and visit my doc ofc).
There are actually more than 10k in total (not planes but models and all can face the camera - however, it isn’t handled in a realtime manner). Rendered with Thea without leaving Rhino.
Don’t want to spam just showing that every user can have different needs. I’d like also notice that this is for rendering purpose which differs a lot from realtime “faceme” handling and if this amount of objects won’t kill your doc it can be achieved with the above scripts.
I found the suggestion of becoming a Rockstar if you need 10 000 people facing you very funny, not the idea of needing it in Rhino…
Everyone uses it differently for different types of projects. Here is one I did last year, 21000 people, all 3d blocks in Rhino working flawlessly real-time in Rhino viewport with shadows, AO etc. (not facing the camera though
Saw those earlier By the way great shots
Me too And actually i have deeper roots in music industry
Jarek “one shot” facing won’t be an issue at all as i said but i bet constant tracking will you provide a slideshow instead of flawless real-time experience
Yes, agreed - unless this is somehow integrated deeply in Rhino display pipeline, it would be very slow with even 100s, not 1000s of objects… One shot solutions exist already, I think what @Micha (and many others) are after, is the real-time implementation. I know too little about coding to suggest technical solutions but would be happy to evaluate any ideas from the user’s standpoint.
I guess your initial idea as a sprite would be straight forward to do, but the question remains what is “the real request” here from most of the users. I wonder how would you approach more complex objects. Any clear ideas?
My best guess for the “need” is to have something very simple (like an image or 2D object) to imitate complex geometry (people, trees). I did not expect any need for more complex objects to be included in this. Basically either a plane or planar object, or a sprite image. This need is both for speed and simplicity of creating such elements from the images with alpha channel…
What would determine the axis or pair of axes each item would rotate about to face the camera? Would it be an axis parallel to the z-axis? What point would remain fixed in space on each object?
@davidcockey I think Jarek proposal sounds very reasonable. I guess that the basic need is for 2 ways in terms of axis handling. Fixed UP (Z) and free to be always parallel to camera. In case of any plane like object they should be oriented using normal of object - using object uvw - v goes always along z /or screenport y and w always towards viewer (dont know what in case of planar curve for eg showing human silhouette since theres no normal - i guess direction could be considered as a decison factor). As a point fixed in space reasonable should be mid point between A and B corner of object bounding rectangle since it seems the most natural decison for “base point”. Does it make sense to you?
lowest point of the Z-axis
@Jarek shouldn’t it be switched to area centroid in case of “free mode” ? It seems more natural in such case.
Oh definitely, if RMA would be willing to make these more sophisticated, I could come up with a few more customizations. My answer was for the plan-minimum…
“Free mode” should use area centroid
Or maybe to make it easier, these objects could be always block instances? Special kind, but then block insertion point would be the rotation pivot point, X axis would be the “face”, and block plane Z would be the rotation axis, with a per-object switch to “keep Z up” or be “freeform”…
So - maybe it would be a block instance property to always face the camera, and if enabled, another switch to keep Z axis up or not. And another switch if “facing” happens in active view only or all viewports… This way it is up to the user to define the blocks correctly, instancing is taken care of, and it would even allow for 3D objects since the “plane” would be clearly defined by the block definition plane.
I can keep going with this … any problems with the above implementation ?
Partially RN does this
I think we should stick with it - i think plan minimum is Z up + free . Blocks imply small problem due to the possibility of nesting but “blocky” solution could be the right way.
can’t wait to try it…
Nested blocks would follow the parent’s “face camera” setting. Would be very cool if nested children with “face camera” also faced the camera while nested…and grandchildren, and…
EDIT: we could have a switch if this is 100% dynamic while changing the view, or update only after view change and camera gets static, or just “on demand”…
I stumbled upon this thread while searching for face-camera components like SketchUp.
What is RN ?
How do I use this?
Kindly share this script as attachment.
RN is shorthand of my plugin name Rhino Nature
Make own button on any toolbar you like and paste the content of this text file and use it as any other command button. It’s as simple as that.
You need to copy the code from the text file to a Rhino button. Later you can press the button and selected surfaces are turned to the camera.
And here an other great old tool. You can create two buttons where the script is recalled. You need to change the path for your setup before:
“Define billboard objects”
-_LoadScript “C:\Program Files\Rhinoceros 6 (64-bit)\Extra64\V4-RotateMapped.rvb” s
“Allign to Camera”
-_LoadScript “C:\Program Files\Rhinoceros 6 (64-bit)\Extra64\V4-RotateMapped.rvb” o
The advantage of this tool is that it can be used for animations per Bongo too.
V4-RotateMapped.zip (1.0 KB)
Thanks. I’ll surely check these out.
Here is the gh definition. It uses the same code as posted previously in this thread.
FaceCamera_GHPY.gh (11.4 KB)
Rhino Version 6 SR22