CyberStretch opened this issue on Aug 31, 2002 ยท 12 posts
CyberStretch posted Sat, 31 August 2002 at 10:08 PM
One of the "little annoyances" I have with Poser is one of the "conveniences" of the package: The Dials. Although the dials are functional, most of the changes require very small changes to the values and relatively small numbers. Therefore, the "real estate" taken up by the "bulky" dials seems like it can be easily recovered by using a digital display (ie [-][0.000][+]) vs the analog dials. I am, by no means, a python scripter; although I have read through some of CLs' PoserPython descriptions in the user manuals and it seems python has almost free reign over many Poser features and functionality. Is something like this even possible? Or would it require a re-write by CL to change all dials into digital displays?
bushi posted Sat, 31 August 2002 at 11:31 PM
While you wouldn't be able to remove the dials, it would be possible to write a script to do as you describe. There are a number of was to implement this but, just off the top, it could work like this. Have a script that would let you select, by name, the dials you want to work with in the scene. The script then opens a small window with the selected dial values displayed as you described. A small button label '+', the value and a small button labeled '-'. You could probably but two of these on the panel in the same space as one standard dial.
CyberStretch posted Sun, 01 September 2002 at 9:39 AM
Thanks bushi. Since I want to make the most out of Poser I am planning on studying python and trying to work its wonders into making Poser that much more worthwhile. I will keep an eye out here as well as hit the python resources as time permits and see what can be done. Although I have been out of programming for, um, quite some time, it may be a slight challenge, but I can usually wrap my head around anything by seeing examples. Thanks again.
ockham posted Sun, 01 September 2002 at 10:38 AM
ockham posted Sun, 01 September 2002 at 11:15 AM
I should add that the number on the Scale can be formatted to any degree of fineness as well. So if you want the slider to show the difference between 0.000003 and 0.000004, you can. Also, you mentioned examples. Here's the code that produces the image above. I'm trying out Bushi's new notational convention here. The bottom part of the code is sort of pointless; I was attempting to rig up a way around the Gimbal Lock problem which didn't work, but at least you can see something happen in response to the sliders. #--------------------------- from Tkinter import * import poser import math RadToDeg = 180.0 / math.pi DegToRad = math.pi / 180.0 startText = "" #----------------------------------------- # Visible part: using Scale sliders. #------------------------ class App: ~def init(self, master, textMessage): ~self.Go = 0 ~self.master = master ~self.deltaX = 0.0 ~self.deltaY = 0.0 ~self.deltaZ = 0.0 ~Label(master, text="x:").grid(row=1, sticky=W) ~Label(master, text="y:").grid(row=2, sticky=W) ~Label(master, text="z:").grid(row=3, sticky=W) ~self.XEntry = Scale(master, from_= -90.0, to=90.0,orient=HORIZONTAL,resolution=1.0) ~self.XEntry.grid(row=1, column=2) ~self.YEntry = Scale(master, from_= -90.0, to=90.0,orient=HORIZONTAL,resolution=1.0) ~self.YEntry.grid(row=2, column=2) ~self.ZEntry = Scale(master, from_= -90.0, to=90.0,orient=HORIZONTAL,resolution=1.0) ~self.ZEntry.grid(row=3, column=2) ~scene = poser.Scene() ~try: ~~self.ca = scene.CurrentActor() ~except: ~~raise("No object selected") ~if not self.ca.IsProp(): ~~raise("Not a prop!") ~self.xParm = self.ca.Parameter("xRotate") ~self.origX = self.xParm.Value() ~self.yParm = self.ca.Parameter("yRotate") ~self.origY = self.yParm.Value() ~self.zParm = self.ca.Parameter("zRotate") ~self.origZ = self.zParm.Value() # Put existing values into the sliders ~self.XEntry.set(self.origX) ~self.YEntry.set(self.origY) ~self.ZEntry.set(self.origZ) # buttons for Go, cancel. ~self.buttonGo= Button(master, text="Go", command=self.handleGo) ~self.buttonGo.grid(row=4, column=1) ~self.buttonGo= Button(master, text="No", command=self.handleCancel) ~self.buttonGo.grid(row=4, column=2) # - - - - - - - - - - - - - - - - - - # Real action happens outside the TK loop, using these vars. #---------------------- ~def handleGo(self): ~~self.Go = 1 ~~try: ~~~self.enteredX = float(self.XEntry.get()) ~~except: ~~~self.enteredX = 0.0 ~~try: ~~~self.enteredY = float(self.YEntry.get()) ~~except: ~~~self.enteredY = 0.0 ~~try: ~~~self.enteredZ = float(self.ZEntry.get()) ~~except: ~~~self.enteredZ = 0.0 ~~self.master.quit() #--------------------- ~def handleCancel(self): ~~self.Go = 0 ~~self.master.quit() #---------------------- # Activate the Win loop, which will be broken by any button. #----------------------- root = Tk() app = App(root, startText) root.mainloop() #---------------------- # End TK loop. #---------------------- if (app.Go): ~# Figure the new angles. ~# Y stays as is. ~# As Y goes to 90, the entered X must affect Z more and X less, ~# which means that the resultant Z takes enteredX * sin Y, ~# and the resultant X takes enteredX * cos Y. ~# As Y goes to 90, the entered Z must affect X more and Z less, ~# which means that the resultant Z takes enteredZ * cos Y, ~# and the resultant X takes enteredZ * sin Y. ~radY = app.enteredY * DegToRad ~resultZ = (app.enteredX * math.sin(radY)) + (app.enteredZ * math.cos(radY)) ~resultX = (app.enteredX * math.cos(radY)) + (app.enteredZ * math.sin(radY)) # Insert the new rots: ~app.xParm.SetValue(resultX) ~app.yParm.SetValue(app.enteredY) ~app.zParm.SetValue(resultZ) ~app.ca.MarkGeomChanged()
bushi posted Sun, 01 September 2002 at 1:23 PM
Cool! You can actually read the script! :) I think I'll go ahead and add the convention details to the page header. Thanks!
ockham posted Sun, 01 September 2002 at 2:53 PM
This script shows one more little problem, namely run-on lines, like this one: ~resultZ = (app.enteredX * math.sin(radY)) + (app.enteredZ * math.cos(radY)) Any ideas for making such an overlap both readable and "copyable"? As long as there's no actual linebreak (BR) within it, the line will come out all right when copied. But the overlapped part falsely appears to be at the left margin.
CyberStretch posted Mon, 02 September 2002 at 11:11 AM
ockham, Thank you for taking the time to write the slider version, it is appreciated. It does show that you can manipulate Poser via python to integrate personal preferences. The reason I suggested a digital display is that it would provide a more compact version of the dials. For example: X: [-][self.xParm][+] X: [-][30][+] saving a little, but possibly valuable "real estate" in the Poser workspace. Also, would the slider version have an absolute minimum/maximum value that you could assign vs an "infinite" min/max by using [-]/[+] with only the value showing? In reading the code, I would presume these are the min/max values: ~self.XEntry = Scale(master, from_= -90.0, to=90.0,orient=HORIZONTAL,resolution=1.0) (I tried to use portions of the script to ensure that I understand it correctly.)
CyberStretch posted Mon, 02 September 2002 at 11:12 AM
hrm... Mental Note: Previewing the message first kind of mucks up the "presentation" as well.
bushi posted Mon, 02 September 2002 at 11:27 PM
@ockham - One of my pet peeves with the forums here is that the text lines will stretch to fill the void if a wide image is attached. I could make up some standard bars say in 80, 96 and 132 character widths that could be attached as an image. Just a .jpg of a thin white bar would work. I could post then in the header here so folks could just grab one and slap it in their post. That should work don't you think?
ockham posted Tue, 03 September 2002 at 11:23 AM
Cyberstretch: Yes, the from_ and to are the min and max settings, but I don't think there's a separate overall max. I think you'll have to create a class including two Buttons and one Editbox to make your version of the dial. This is easier than it sounds; you can look at the TKinter code in the Python runtime folder within Poser for examples of "widget" classes that you can modify. Some good intro guides to TKinter are in the Library section of pythonware.com, but Grayson's book on TKinter is the best help. Bushi: It took me a minute to see what you're doing.... turning a bug into a feature. Yes, good idea. Magic Margin bars.
CyberStretch posted Tue, 03 September 2002 at 1:12 PM
Thanks for all the suggestions and input, a very valuable resource when you are just starting out.