How can I add construction points by x,y,z location?

Krisidious

How can I add construction points by x,y,z location? I have these 3D locations in this format pos=(0.70,0.0,-1.34) ori=(0.0,0.0,0.0) and need to make construction points from them. is there an easy way to do it?

Dave R

Didier Bur's Points Cloud plugin could do it.

Linkity link: http://rhin.crai.archi.fr/rld/plugin_details.php?id=777

TIG

First set you Model Info > Units to match the file's units.
Assuming that these points are in a file with one line per point, in the form
pos=(0.70,0.0,-1.34) ori=(0.0,0.0,0.0) you'll need to do something like this... in the Ruby Console...
Set a reference to this 'file of points'... e.g.

f='C;\Temp\points.txt';

i.e. set it to your REAL file's path.
Then run this one liner...

IO.readlines(f).each{|t|next if t.empty? or not t=~/[(]/;p=t.split('(')[1].split(')')[0].tr(' ','').split(',');Sketchup.active_model.active_entities.add_cpoint([p[0].to_l,p[1].to_l,p[2].to_l])}

Note how the various coded 'splits' etc parse the strings at the '(' and ')', remove any 'whitespace', and then divides the point that's left at the ',' to get the X,Y,Z values for that point [see how the '.to_l' says make the 'string' into a 'length' - hence the need to match the model's units to the file's] and it then adds the cpoint using those...
This is specific to your file's format, it can be readily adjusted to suit other configurations of data...

Krisidious

thanks Dave and Tig,

I'm running into an issue. are XYZ not universal? why do different 3D programs use different XYZ? I can understand X & Y being mixed up but Z? here is the top of my code. and a bit of the locations I'm dealing with.

/////////////////////////////////////////////////////////////////////////////
//
// Conventions;
//
// +x = left
// +z = rear
// +y = up
// +pitch = nose up
// +yaw = nose right
// +roll = right
//
// [BODY]  - a rigid mass with mass and inertial properties
// [JOINT] - a ball joint constraining an offset of one body to an
//           offset of another body (eliminates 3 DOF)
// [HINGE] - a constraint restricting the relative rotations of two
//           bodies to be around a single axis (eliminates 2 DOF).
// [BAR]   - a constraint holding an offset of one body from an offset of
//           another body at a fixed distance (eliminates 1 DOF).
// [JOINT&HINGE] - both the joint and hinge constraints, forming the
//           conventional definition of a hinge (eliminates 5 DOF).
//
/////////////////////////////////////////////////////////////////////////////

// Body including all rigidly attached parts (wings, barge boards, etc.)
[BODY]
name=body mass=(1562.0) inertia=(1856,2194,495.0)
pos=(0.0,0.00,0.0) ori=(0.0,0.0,0.0)

// Front spindles
[BODY]
name=fl_spindle mass=(22.0) inertia=(0.0325,0.0305,0.0285)
pos=(0.70,0.0,-1.34) ori=(0.0,0.0,0.0)


[BODY]
name=fr_spindle mass=(22.0) inertia=(0.0325,0.0305,0.0285)
pos=(-0.70,0.0,-1.34) ori=(0.0,0.0,0.0)

// Front wheels
[BODY]
name=fl_wheel mass=(26.0) inertia=(2.100,1.220,1.220)
pos=(0.764,0.0,-1.34) ori=(0.0,0.0,0.0)

[BODY]
name=fr_wheel mass=(26.0) inertia=(2.100,1.220,1.220)
pos=(-0.764,0.0,-1.34) ori=(0.0,0.0,0.0)

// Live rear axle
[BODY]
name=rear_axle mass=(120.00) inertia=(10.70,10.70,5.20)
pos=(0.0,-0.07,1.30) ori=(0.0,0.0,0.0)

// Rear wheels 
[BODY]
name=rl_wheel mass=(30.0) inertia=(2.110,1.225,1.225)
pos=(0.715,0.0,1.35) ori=(0.0,0.0,0.0)

[BODY]
name=rr_wheel mass=(30.0) inertia=(2.110,1.225,1.225)
pos=(-0.715,0.0,1.35) ori=(0.0,0.0,0.0)

// Fuel in tank is not rigidly attached - it is attached with springs and
// dampers to simulate movement.  Properties are defined in the HDV file.

[BODY]
name=fuel_tank mass=(1.5) inertia=(1.0,1.0,1.0)
pos=(0.0,0.0,0.0) ori=(0.0,0.0,0.0)

// Driver's head is not rigidly attached, and it does NOT affect the vehicle
// physics.  Position is from the eyepoint defined in the VEH file, while
// other properties are defined in the head physics file.

[BODY]
name=driver_head mass=(6.0) inertia=(0.035,0.025,0.030)
pos=(0.0,0.0,0.0) ori=(0.0,0.0,0.0)

TIG

Most 3d CAD programs like SUp now have X and Y on the ground [right/left and back/front] and Z is up/down.
Old 2d/3d CAD programs used 'width' =X and 'depth =Y, with 'height' =Z.
This is confusing even in the SUp's API bounding box methods which returns these unexpectedly too, so 'height' is measured in the Y, while 'depth' is measured the Z and X is measured as the 'width'...
The typical 'flip' is that of Y and Z, with a -ve value for the Y to make it a proper Z in the other file's format... So that SUp file then suits say OBJ format... conversely importing an OBJ file into a SKP you must flip Y/Z backwards to suit the SKP...

Krisidious

Thanks Tig...

one more question... is red guide in SU X or Y?

Dave R

Red is X.

Krisidious

thank you sir.

TIG

RGB = XYZ [in SUp!]

Krisidious

oh that makes nice sense. good to know. thank you.