@encephalon I think you took my words a bit too personal. Actually, I catch myself many times saying “hey! why? it’s so simple!” and then I quickly realize I was wrong.
I didn’t aim to “win” any debate and I think it would be good to continue this talk and express what kind of behavior from this particular feature is expected this will for sure help in defining the most typical use scenario. I just pointed out that it is not necessarily that simple as many of us can think.
Making simple quads with a single texture could be relatively easy, but I guess it wouldn’t be the thing which we would expect from this feature and as soon as we would like to “faceme” some other object this topic would return. So it would be just better to use our “collective intelligence” ( cite @HS_Kim ) and propose its behavior for typical use scenarios on different objects or it should be just a totally different object used indeed only as a billboard plane.
i understand your concerns, still diagnosing somebody with mental illnesses is not a very fruitful foundations for further discussions. i am sure there are tricky parts to solve, none of which i actually addressed in detail (ok almost not), which i believe seems to be the misunderstanding.
under the line this function is something “simple” which seems to develop huge concerns, not sure how i can state this more or lets say less elaborate
Yes just because of fact that redrawing bigger amount of this objects can have a very big impact on viewport performance - being that said SU viewport performance is faaaar from perfect i think we all agree here - that’s why few solutions were concerned.
I think from UI side this could be done in two ways one in object properties checkbox “faceme” or in a command way launched for certain object and it should be locked for one viewport lets say active one in which those objects will be shown in case of change objects would disappear from another one - and here i see next problem - what is someone want to use it for layout ? It will have to be transformed many times in one place and drawn differently in different layouts(?) - which view it should fit in a situation where we have 4 views on one sheet of paper? One object many transform states at once implies a massive headache for me
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
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
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?
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 ?
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.
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”…
) and propose its behavior for typical use scenarios on different objects or it should be just a totally different object used indeed only as a billboard plane.
And actually i have deeper roots in music industry 