[Solved] User Attributes | transforming calculated data

ghpython
usertext
grasshopper

(IVELIN PEYCHEV) #1

Hi,

How can I transform attributes that are calculated from the object to numbers with ghpython?
(e.g. % < Area > %)

3dm%20(41%20KB)%20-%20Rhinoceros%206%20Commercial%20-%20%5BPerspective%5D

output_as_input(or%20alternative)_

Can I create my own calculated attributes?

Thanks in advance


(Giulio Piacentino) #3

This is something having to do with the way Rhino parses these special strings. I think @lowell might know how this is wrapped to .Net, or @Alain.


Changing point style of a UserObject's output points
(Travis Serio) #8

Ahh yes, you will need to rely on the RhinoCommon to get the solution. You can do this by using RhinoApp.ParseTextField and passing in the value formatted like this with your object guid %<Area(“8974f391-92da-413b-bd36-a2bd263ee91e”)>% and the rhino object and any parent object if required (otherwise null parent). This will return the computed area result that you see in the object attributes panel.


(Travis Serio) #9

Heres a quick and dirty example


getusertextfunctionvalues.gh (12.4 KB)


(Chris Hanley) #10

Thanks for this! Quick question @Trav in your example, you don’t have:

import scriptcontext as sc
#set focus on Rhino document
sc.doc = Rhino.RhinoDoc.ActiveDoc
   #do something in the Active Rhino Document
#set focus back on GH document
sc.doc = ghdoc

Has something changed in recent updates that the ghpython component handles this automatically? I was unable to get your example to work without it? (I added it into code below to get your example to work).

import rhinoscriptsyntax as rs
import scriptcontext as sc

sc.doc = Rhino.RhinoDoc.ActiveDoc

keys = rs.GetUserText(x)
#obj = sc.doc.Objects.Find(x)
obj = rs.coercerhinoobject(x)

values = []
parsed = []

for key in keys:
    v = rs.GetUserText(x,key)
    values.append(v)
    p = Rhino.RhinoApp.ParseTextField(v, obj, None)
    parsed.append(p)
    
a = keys
b = values
c = parsed

sc.doc = ghdoc

(Travis Serio) #11

@chanley you are most likely correct, just to be sure I have updated the source example. Thanks!


(Chris Hanley) #12

Thanks for clarifying! I thought I remembered reading somewhere that there was some discussion about changing some default behavior in the ghpython component and I was wondering if something had changed…(perhaps I’m remembering incorrectly).

Anyway, thanks again for your help! I used your tip to update one of our studio’s components! In case it helps anyone else, here is an example using only RhinoCommon VS (mostly)RhinoScript.


objAtts_ghpython.gh (15.3 KB)

NOTE: the order of the keys in this example is not sorted. The order is coming directly from the order in which they were created on the object.


(IVELIN PEYCHEV) #13

@Trav, @chanley,

Thank you both for the help, this is exactly what I needed.

Could you also answer the second part of my question?

Clearly having only ‘Area’ and ‘Curve Length’ is not enough. I would like to set other calculated stuff like Moments, Volumes, Weight, etc.


(Travis Serio) #14

@ivelin.peychev currently , for today, what is listed are the only ones we have. However, we are working hard on figuring out the best way to expand that functionality without affecting performance, model integrity, and security. It’s high on my personal priority list if that helps.


(IVELIN PEYCHEV) #15

I see. Thanks for the info.

I don’t know how you do things in McNeel. Are you implementing the functionality before providing API or both at the same time? If there’s already some API perhaps I can try to mess around with it.


(Travis Serio) #16

Both at the same time. ParseTextField wraps a C++ function that processes the actual string and computes the requested function. The list of commands that it understands and processes are what we currently expose in the functions dialog. Today it only does a few things as you’ve seen but could potentially be expanded with several new items as well as possibly support some basic scriptable input.

Since you’re using grasshopper you could definitely add additional ways to get that data from the objects, or does your workflow require the data come from user text?


(IVELIN PEYCHEV) #17

Ultimately, both. Attributes some calculated some entered by the user.

UserObjects (I call them attributes because they correspond to attributes in other 3d modeling software)

Yes, I use Grasshopper. However, I think that without user interaction with the goo and/or a goo-less GH (baking to be removed/unnecessary).
Its (GH) usefulness is limited for some (arguably many) industries. That’s why I hope in the future object attributes (user objects) to lead the parametrization/automation inside GH.

Btw, I don’t know of McNeel plans, but these object attributes will best fit in a database infrastructure :wink:


(Travis Serio) #18

This is part of the ongoing conversation about how all of this data moves forward. Honestly, user text and document text are too limited to really do what we all want.


(IVELIN PEYCHEV) #19

True that! Perhaps its release should’ve been delayed until a bit more mature. Nevertheless, still it has its usefulness. Keep it up!

I’m looking forward to see how DB implementation will look like. I can imagine it’s not an easy task. I know the struggle other software companies had adjusting all types. Eventually it was all worth it.

Could you share which DB you decided on using? MSSQL, Oracle, MySQL (Oracle)?


(Travis Serio) #20

They have always been there. 6 just gave them a user interface.


(IVELIN PEYCHEV) #21

Wow, I didn’t know they existed in previous versions. I worked on 3, 4, 5 and now on 6 :smiley:


(Travis Serio) #22

Yeah they were only accessible via the Command line GetUserText and GetDocumentText. Primarily used for scripting purposes. Now that they have a user interface more and more requests are coming in to expand their usefulness as people start working with them more and more.