Control Point 1 dimension

[Gregi]

Hello Forum one more time

 

I would really love to have an Control Point-Handle for just one direction (X,Y or Z), the other dimensions as an input port.

So in the end in the OIP theres only one field which i could use in the marionette-object as dynamic parameter. All my tries were unsuccessful.

[Gregi]

So, some more information, i still get stucked

 

I would like to have a parametric marionette object with input fields and control-points. a control point should only set one parameter and should be placed depending on other parameters. so i tried to change some codes with kind of succes, but now i got three problems:
1. the with/"Breite" (X) parameter ist not visible in the oip

2. every other input field like "dim" node is resetting after moving an control point

3. i would like tho have NO OIP-Control about the not-used control point (CP_1dim_20-04-23.vwxy in the #OIP Controls in my example) but were not succesfull, is there any possibility to do?

 

#Created January 2018
#Updated August 2018
@Marionette.NodeDefinition
class Params(metaclass = Marionette.OrderedClass):
#APPEARANCE
	#Name
	this = Marionette.Node('Control Point 2D')
	this.SetDescription('Creates a 2D reshape handle when used in a Marionette Object. Initial values are defined in the Object Info Palette.')

	#Input Ports
	fy = Marionette.PortIn(0.0)
		
	#OIP Controls
	x = Marionette.OIPControl( 'X', Marionette.WidgetType.RealCoord, 0.0)
	x.SetDescription('A value representing the distance from the origin along the x axis')
	y = Marionette.OIPControl( ' ', Marionette.WidgetType.Separator, '')
	#y.SetDescription('A value representing the distance from the origin along the y axis')
	
	#Output Ports
	pt = Marionette.PortOut('p')
	pt.SetDescription('A Control 2D point on the xy plane')

#BEHAVIOR
	
def RunNode(self):
	#inputs
	x = self.Params.x.value
	#y = self.Params.y.value
	#y = 50.0
	y = self.Params.fy.value
	appMajor, appMinor, appMaint, platform = vs.GetVersion()	
	units = vs.GetPrefReal(150)	
	#script
	pioHandle = vs.Handle(Marionette.parametric_handle) 
	if pioHandle != vs.Handle(0):
		if appMajor >=24:
			Marionette.CreateControlPointCoord(self.Handle, x, y)
			x = x/units
			y = y/units
		else:
			x = x/units
			y = y/units
	else:
		x = x/units
		y = y/units
	#outputs
	self.Params.pt.value = (x, y)
	

 

[Gregi]

Or, another example to show what i would like to get. An invisible OIP widget for control points would be a good beginning. is something like this possible?

 

[Gregi]

Is there any function reference for

vs.Mrntte_ControlPoint(nodeHandle, coordX, coordY, coordZ, False)

I realized, the second Var (here coordY) is always changing the second OIP-Control, doesn't matter which name is given in the inputs.

 

In my test the second one is giving the Point i want to have, the blue handle is shown at y=100, doesn't matter, where i put the point. But in OIP it chances the Variable.

If i delete "ydummy" in the #OIP Controls, every moving in Y-Axis is shown in the "Z" Value, and no moving in Z-Axis is possible.

 

How could the function be Chanced? do you have an idea @sbarrett @DomC

 

 

 

 

 

CP_1dim_2020-11-17.vwx

Edited March 19, 2021 by Gregi

[MrPilot]

Anyone from Vectorworks care to answer? The code behind this node is buggy and we really would like this to work. It's bloody tiring to get stuck for hours on such topics, and a great reason to switch away from Vectorworks.

 

@sbarrett @DomC @ComputerWorks

Edited September 11, 2023 by MrPilot

[Antonio Landsberger]

Hi @MrPilot,

Quote

The code behind this node is buggy

 

Ok, which node is buggy? This topic is about different OIP controls and some custom nodes.

 

How is the node buggy? What is happening with which steps and what would be the expected behaviour instead?

In which Vectorworks version is it buggy?

Do you have a document, with which this bug can be seen?

 

Have you contacted your local distributor about this?

[DomC]

Marionette is a Programming-Tool. In such tools wer are in a place to have the force to produce wonderful artwork or unwanted behaviors (crashes?) and comparative we are mostly alone with our artworks. And thanksfully there are forums like this other people can help for bringing those projects to success.

I took a look a the Marionette Control-Point and agree,  there is some space for improvement:

1. Fixing Axis
I think @Gregi wantet to fix one axis. This is not possible because the position of the control-point  comes from the Mouse not from a value inside the script. This value is just a default value. To change the control point by script itself is theoretically possible to manipulate the Record of the Marionette Node where the position of the point is stored but it would be very hard (Because also the position of the PIO is involved). So this is not a bug it works the way the feature is designed.

2. Moving 3D Point in Standard View.
If I am in a standard view (front right etc.). Lets say from right and I move the point in z-Direction, the x value from the point snaps on the working plane and the x-value gets 0. Which can maybe produces issues in the script inside the PlugIn. So working plane should be used or unwanted values have to be intercepted inside the script (which is always the most costly part). So if the script crash because the width of the pio change to 0 it is not a bug in the code of the 3D modification point. It is just an unhandled error. Error can be handled on different places. In shoft:
OK, I can see, that the reshape behaviour of this modi-point can be improved and i will report this as an enhancement Request.

3. Position of the 3D Point outside of PIO geometry.
If the Modification Point is the most outside object in a PlugIn. And not geometry is there, the position of the Point somehow is calculated wrong relatively to the object. So in our test with Extrudes etc. it always works as expected. But If the extrude is smaller than the bbox of the modipoint and the 0-point it somehow Fails.
I think, this is definitely a bug. I will report.

4. Position of the 3D Point with layer elevation

I think this is already known but I try to give it an impact.

Generally, there are not much additional layers of error-handling between marionette and the Script Engine. I think the more "idiot-proof" something is made the weaker it is. Not 100% the truth (It could be possible to have both). But this is the way I am still pleased even if my script crashes 😁

[MrPilot]

@Antonio Landsberger & especially @DomC many thanks for your responses. Unfortunately I'm not a very frequent user of forums (maybe I could improve in this regard somewhat?) – but appreciate you taking the time to respond. Agreed that too much "idiot-proofing" prevents flexibility, and I'm all about being free to code whatever I want. However it's important that bugs (as @DomC you seem to have confirmed) should still be reported and corrected... if a given functionality is provided as part of a proprietary package (vs open-source), we have to rely on the vendor to make adjustments and corrections. Anyhow, many thanks for reporting, and looking forward to seeing if this node can be updated 🙂