Forum Moderators: Staff
Poser Technical F.A.Q (Last Updated: 2024 Dec 04 2:47 am)
Welcome to the Poser Technical Forum.
Where computer nerds can Pull out their slide rules and not get laughed at. Pocket protectors are not required. ;-)
This is the place you come to ask questions and share new ideas about using the internal file structure of Poser to push the program past it's normal limits.
New users are encouraged to read the FAQ sections here and on the Poser forum before asking questions.
Attached Link: Cannon1 example (50 KB)
This is looking great. I'm going to use Taylor series to set up the basic trig functions in a week or two. With degree 5 polynomial expansions, we should be able to get good approximations in the 0 to 90 degree range.
View Ajax's Gallery - View
Ajax's Freestuff - View
Ajax's Store -
Send Ajax a message
That graph looks good. I'm a bit worried about the potential for divide by zero errors though, which is another advantage of Taylor series. Have you tried stacking the operators within a single channel? For example, is it possible to get a power by just putting multiple valueOpTimes lines in a single channel?
View Ajax's Gallery - View
Ajax's Freestuff - View
Ajax's Store -
Send Ajax a message
These new operators, what are we going to call them? They're outside the bounds of ERC, which really refers specifically to the sytem Poser uses for the type of remote control seen in full body morphs. We could put another E on there for Extended but since the E in ERC already stands for Enhanced, that doesn't seem so good. My suggestions are either MORC (mathematical operator remote control) or, my preferred option, ARC (arithmetic remote control). What do guys think? Should we call this stuff ARC?
View Ajax's Gallery - View
Ajax's Freestuff - View
Ajax's Store -
Send Ajax a message
Well, from the programer's point of view, valueOps are valueOps, whatever they eventually do (or don't do :). But a new word for the new valueOps is more user-friendly, I think. I vote for ARC (shorter, and MORC sounds like MAT & MOR stuff). BTW, I tried different implementations for the series expansion of sine. The first example is a degree 9 polynomial. The 1/3!, 1/5! etc. are solved to 8 decimals precision, and set as initialValue and "k" value in the "sn_exp" channels. The code is very compact (8 channels). Unfortunately, it creates a considerable error (ymax is at x=1.435, y=0.951): translateX xtran valueParm sn_xmult ..........valueOpDeltaAdd ....................xtran ..........deltaAddDelta 1 valueParm sn_xsquare ..........valueOpDeltaAdd ....................xtran ..........deltaAddDelta 1 ..........valueOpTimes ....................sn_xmult valueParm sn_exp3 ..........initValue 0.16666667 ....................k 0.16666667 ..........valueOpTimes ....................sn_xsquare ..........valueOpTimes ....................sn_xmult valueParm sn_exp5 ..........initValue 0.00833334 ....................k 0.00833334 ..........valueOpTimes ....................sn_exp3 ..........valueOpTimes ....................sn_xsquare valueParm sn_exp7 ..........initValue 0.00019841 ....................k 0.00019841 ..........valueOpTimes ....................sn_exp5 ..........valueOpTimes ....................sn_xsquare valueParm sn_exp9 ..........initValue 2.75e-06 ....................k 2.75e-06 ..........valueOpTimes ....................sn_exp7 ..........valueOpTimes ....................sn_xsquare translateY yTran ..........valueOpDeltaAdd ....................xtran ..........deltaAddDelta 1 ..........valueOpMinus ....................sn_exp3 ..........valueOpPlus ....................sn_exp5 ..........valueOpMinus ....................sn_exp7 ..........valueOpPlus ....................sn_exp9 The second example is again the degree 9 expansion. The 3!, 5! etc. divisors are set as initValue and "k" value, and Poser calculates the quotients in extra "sn_div" channels. The "valueOpDivideInto" is secure in this case, since the divisor is a static value >0. The code needs 1 channel more per term (12 instead of 8), but it's very accurate (ymax at x=1.5708, y=1.000): translateX xtran valueParm sn_xmult ..........valueOpDeltaAdd ....................xtran ..........deltaAddDelta 1 valueParm sn_xsquare ..........valueOpDeltaAdd ....................xtran ..........deltaAddDelta 1 ..........valueOpTimes ....................sn_xmult valueParm sn_exp3 ..........valueOpDeltaAdd ....................sn_xsquare ..........deltaAddDelta 1 ..........valueOpTimes ....................sn_xmult valueParm sn_div3 ..........initValue 6 ....................k 6 ..........valueOpDivideInto ....................sn_exp3 valueParm sn_exp5 ..........valueOpDeltaAdd ....................sn_exp3 ..........deltaAddDelta 1 ..........valueOpTimes ....................sn_xsquare valueParm sn_div5 ..........initValue 120 ....................k 120 ..........valueOpDivideInto ....................sn_exp5 valueParm sn_exp7 ..........valueOpDeltaAdd ....................sn_exp5 ..........deltaAddDelta 1 ..........valueOpTimes ....................sn_xsquare valueParm sn_div7 ..........initValue 5040 ....................k 5040 ..........valueOpDivideInto ....................sn_exp7 valueParm sn_exp9 ..........valueOpDeltaAdd ....................sn_exp7 ..........deltaAddDelta 1 ..........valueOpTimes ....................sn_xsquare valueParm sn_div9 ..........initValue 362880 ....................k 362880 ..........valueOpDivideInto ....................sn_exp9 translateY yTran ..........valueOpDeltaAdd ....................xtran ..........deltaAddDelta 1 ..........valueOpMinus ....................sn_div3 ..........valueOpPlus ....................sn_div5 ..........valueOpMinus ....................sn_div7 ..........valueOpPlus ....................sn_div9
Attached Link: Sine Prop (5KB)
Attached Link: http://www.renderosity.com/mod/freestuff/details.php?item_id=70460
Hello all,We are January 2013. After creating my ERC Trajectory Prop (to be found in the freestuff section, see the attached link), I discover this thread. So, for those of you that reach this thread, you can also look at my freestuff. There is a detailed tutorial included with the package. You will see that I use also various operators and that the basic concept are quit similar to those of VK
Allstereo
This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.
![file_58229.jpg](https://live.cdn.renderosity.com/forum/_legacy/file_58229.jpg)
The "valueOpTimes" operator in ERC slave code can be used to easily create parabolic-like (curved) tran dials. The curved movement consists of 2 components, for example the xtran and the ytran channels of the example prop "ball_1". One of the channels is the master (xtran, in this example), the other one the slave (ytran). The ERC slave code is a combination of the "valueOpDeltaAdd" and "valueOpTimes" operators. The ytran slave channel looks like this: translateY ytran { name GetStringRes(1028,13) etc... interpStyleLocked 0 valueOpDeltaAdd _NO_FIG_ ball_1 xtdriver deltaAddDelta 1.000000 valueOpTimes _NO_FIG_ ball_1 xtran } Note that the "valueOpDelta" operator comes first, followed by the "valueOpTimes" operator. At runtime, the ytran slave is first affected by valueOpDeltaAdd, which moves ytran to a non-zero value. Then, the new non-zero ytran is affected by valueOpTimes, which moves ytran to ytran * xtran. You can use the deltaAddDelta in ytran, or the ytran dial, to adjust the curve. The two valueOps must be controlled by two separate master channels. Therefore, you need an extra valueParm channel, which is a slave of the xtran master, and a master of the ytran slave. In this example, the extra master channel is "xtdriver". In the ytran slave code, the "valueOpDeltaAdd" operator points at master "xtdriver", the "valueOpTimes" operator points at master "xtran". Channel "xtdriver" simply transmits the motion of the xtran master to the ytran slave, so that the valueOps in the ytran slave are controlled by two masters. The channel code looks like this: valueParm xtdriver { name driveXTran initValue 0 etc.... interpStyleLocked 0 valueOpDeltaAdd _NO_FIG_ ball_1 xtran deltaAddDelta 1.000000 }