pipmak-users — Content creation for the Pipmak Game Engine

Re: Video patches

[Christian W. <cwa...@gm...>]

Hello Vobla, and welcome!

> I'm new to this forum and just wanted to ask if the developers of  
> Pipmak are
> still working on the engine and will we see the features listed in  
> To-do
> list?

I guess that depends on your definition of "still working"... I can't  
deny that I have made very little progress on it in the last few years  
(and apparently everybody else as well), so the project is indeed a  
bit stagnant now. That is unlikely to suddenly change in a big way.  
However, I am still working on it in the sense that I consider it  
neither finished nor abandoned, there is still much to do and I do  
intend to get to it eventually -the slowness is just because I have  
been busy with lots of other interesting things.

I cannot commit to any timing estimates for specific features - I  
don't have any concrete timetable for working on Pipmak and it's hard  
to make any predictions on what will be victorious in the competition  
for my scarce spare time at any given time. It also depends a bit on  
how I perceive activity and demand, e.g. here on the mailing lists. Do  
you have any specific needs, are you working on a concrete project?

  -Christian

Automatic rotation of panoramas

[James C. W. <jfc...@ya...>]

Hi all,
 
Sorry to bring this up again, but I've encountered another problem with my auto-panning function. Namely, the camera slows down exponentially as it rotates. This is because the local variables "autoPan_speedAZ" and "autoPan_speedEL" are updated every repitetion, so that the camera doesn't lose track of its target if the user moves the view themselves. Is there a way to make up for the decrease in speed?
 
Thanks,
   James CW
 
 
 
************CODE***************
 
function autoPan(autoPan_tarAZ, autoPan_tarEL, autoPan_length) 
local autoPan_rate = 0.025            
local autoPan_viewAZ, autoPan_viewEL = pipmak.getviewdirection()  
local autoPan_speedAZ, autoPan_speedEL = 0, 0
local autoPan_iterCount = nil 
            
 
pipmak.schedule(
    autoPan_rate,                 
  function() 
      if autoPan_iterCount == nil then                           
        autoPan_iterCount = autoPan_length / autoPan_rate 
      end                    
      autoPan_viewAZ, autoPan_viewEL = pipmak.getviewdirection()  
      autoPan_speedAZ = (autoPan_tarAZ - autoPan_viewAZ) / autoPan_iterCount )   
      autoPan_speedEL = (autoPan_tarEL - autoPan_viewEL) / autoPan_iterCount )
      if autoPan_viewAZ + 0.1 > autoPan_tarAZ and autoPan_viewAZ - 0.1 < autoPan_tarAZ and autoPan_viewEL + 0.1 > autoPan_tarEL and autoPan_viewEL - 0.1 < autoPan_tarEL then
        autoPan_iterCount = nil                                    
        pipmak.setviewdirection(autoPan_tarAZ, autoPan_tarEL)
        return                                                     
      else                                                        
        pipmak.setviewdirection(autoPan_viewAZ + autoPan_speedAZ, autoPan_viewEL + autoPan_speedEL ) 
      end
      return autoPan_rate                             
   end
  )
end


      

Video patches

[Vobla <led...@gm...>]

Hi there everybody,

I'm new to this forum and just wanted to ask if the developers of Pipmak are
still working on the engine and will we see the features listed in To-do
list?

If yes, when?


Thanks!
-- 
View this message in context: http://old.nabble.com/Video-patches-tp28727532p28727532.html
Sent from the pipmak-users mailing list archive at Nabble.com.

Re: Increasing volume: A possible Bug: Resend

[James C. W. <jfc...@ya...>]

Thanks Christian!
 
-James CW

--- On Sat, 5/22/10, Christian Walther <cwa...@gm...> wrote:


From: Christian Walther <cwa...@gm...>
Subject: Re: Increasing volume: A possible Bug: Resend
To: "Content creation for the Pipmak Game Engine" <pip...@li...>
Date: Saturday, May 22, 2010, 9:19 AM


> Am I doing the correct thing here? If I change the volume of a sound  
> to "volume = 3", the volume does not increase. If I set it to 0.5,  
> however, it does decrease.
> Does anyone know why this is?

Right, I can reproduce that. It turns out that it's a bug in the  
documentation. OpenAL is not guaranteed to support overall gain > 1.0,  
so always clamping it to 1.0, as Pipmak currently (unintentionally)  
does, seems like the best choice for consistence among different  
implementations. All we can do is change the documentation to reflect  
that - which I just did.

You should make your sound files loud enough that they never need  
amplification greater than 1.

Thanks for the report!

  -Christian

------------------------------------------------------------------------------

_______________________________________________
Pipmak-Users mailing list
Pip...@li...
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users



      

Re: Increasing volume: A possible Bug: Resend

[Christian W. <cwa...@gm...>]

> Am I doing the correct thing here? If I change the volume of a sound  
> to "volume = 3", the volume does not increase. If I set it to 0.5,  
> however, it does decrease.
> Does anyone know why this is?

Right, I can reproduce that. It turns out that it's a bug in the  
documentation. OpenAL is not guaranteed to support overall gain > 1.0,  
so always clamping it to 1.0, as Pipmak currently (unintentionally)  
does, seems like the best choice for consistence among different  
implementations. All we can do is change the documentation to reflect  
that - which I just did.

You should make your sound files loud enough that they never need  
amplification greater than 1.

Thanks for the report!

  -Christian

Increasing volume: A possible Bug: Resend

[James C. W. <jfc...@ya...>]

Sorry, I accidentally hit Send before I was finished typing:
 
Hi all,
 
Am I doing the correct thing here? If I change the volume of a sound to "volume = 3", the volume does not increase. If I set it to 0.5, however, it does decrease.
Does anyone know why this is?
 
Thanks, 
  James


      

Increasing Volume: A possible bug

[James C. W. <jfc...@ya...>]

Hi all,
 
Am I doing the correct thing here?
 
volume = 3


      

Re: How does Pipmak.getimage work?

[James C. W. <jfc...@ya...>]

Thanks, Christian.

-James

--- On Mon, 4/19/10, Christian Walther <cwa...@gm...> wrote:

> From: Christian Walther <cwa...@gm...>
> Subject: Re: How does Pipmak.getimage work?
> To: "Content creation for the Pipmak Game Engine" <pip...@li...>
> Date: Monday, April 19, 2010, 1:46 PM
> > Am I correct in assuming that
> the decompressed image in RAM would be  
> > the same filesize as a BMP version of the same image?
> 
> Probably. 4 bytes per pixel for an RGBA image, 3 bytes per
> pixel for  
> an RGB image, plus maybe 100 bytes of header information
> per image.  
> Pipmak keeps in memory the pixel data of all images that
> are in use as  
> RGBA node backgrounds (for insideness testing) and hotspot
> maps, plus  
> the last-used 20 MB worth of pixel data of currently unused
> images (to  
> speed up loading of already visited nodes). Not all images
> that are  
> currently being displayed are necessarily kept in memory
> (by Pipmak at  
> least, your OpenGL driver may do it anyway), since they are
> displayed  
> from video memory. Pixel data is loaded from disk whenever
> it is  
> needed and not already in memory. In addition, the
> Lua-accessible  
> image objects (whether their pixel data is in memory or
> not) are  
> cached separately until Lua garbage-collects them.
> 
>   -Christian
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling,
> find bugs
> proactively, and fine-tune applications for parallel
> performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Pipmak-Users mailing list
> Pip...@li...
> news://news.gmane.org/gmane.games.devel.pipmak.user
> https://lists.sourceforge.net/lists/listinfo/pipmak-users
> 


      

Re: How does Pipmak.getimage work?

[Christian W. <cwa...@gm...>]

> Am I correct in assuming that the decompressed image in RAM would be  
> the same filesize as a BMP version of the same image?

Probably. 4 bytes per pixel for an RGBA image, 3 bytes per pixel for  
an RGB image, plus maybe 100 bytes of header information per image.  
Pipmak keeps in memory the pixel data of all images that are in use as  
RGBA node backgrounds (for insideness testing) and hotspot maps, plus  
the last-used 20 MB worth of pixel data of currently unused images (to  
speed up loading of already visited nodes). Not all images that are  
currently being displayed are necessarily kept in memory (by Pipmak at  
least, your OpenGL driver may do it anyway), since they are displayed  
from video memory. Pixel data is loaded from disk whenever it is  
needed and not already in memory. In addition, the Lua-accessible  
image objects (whether their pixel data is in memory or not) are  
cached separately until Lua garbage-collects them.

  -Christian

Re: How does Pipmak.getimage work?

[James C. W. <jfc...@ya...>]

Hi Christian,

I'm working on scripting a sort of very basic particle system, and I wanted to know how much memory the operation would eat.
Am I correct in assuming that the decompressed image in RAM would be the same filesize as a BMP version of the same image?

Thanks,
  James

--- On Mon, 4/19/10, Christian Walther <cwa...@gm...> wrote:

> From: Christian Walther <cwa...@gm...>
> Subject: Re: How does Pipmak.getimage work?
> To: "Content creation for the Pipmak Game Engine" <pip...@li...>
> Date: Monday, April 19, 2010, 12:35 PM
> > How does Pipmak.getimage work,
> when it creates an image object? Does  
> > it decompress the image and drop it into the RAM?
> 
> Basically, yes. Why and in how much detail do you need to
> know? If you  
> want the most accurate description possible, you can always
> read the  
> code: <http://pipmak.svn.sf.net/viewvc/pipmak/trunk/pipmak/source/pipmakLuaLib.c?revision=226&view=markup#l_496
> 
>  >.
> 
>   -Christian
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling,
> find bugs
> proactively, and fine-tune applications for parallel
> performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Pipmak-Users mailing list
> Pip...@li...
> news://news.gmane.org/gmane.games.devel.pipmak.user
> https://lists.sourceforge.net/lists/listinfo/pipmak-users
> 


      

Re: How does Pipmak.getimage work?

[Christian W. <cwa...@gm...>]

> How does Pipmak.getimage work, when it creates an image object? Does  
> it decompress the image and drop it into the RAM?

Basically, yes. Why and in how much detail do you need to know? If you  
want the most accurate description possible, you can always read the  
code: <http://pipmak.svn.sf.net/viewvc/pipmak/trunk/pipmak/source/pipmakLuaLib.c?revision=226&view=markup#l_496 
 >.

  -Christian

How does Pipmak.getimage work?

[James C. W. <jfc...@ya...>]

Hi all,
 
How does Pipmak.getimage work, when it creates an image object? Does it decompress the image and drop it into the RAM? Or something else?
 
Thanks,
  James CW


      

Sound volume/pitch problems

[James C. W. <jfc...@ya...>]

Hi all,
 
If I set the pitch of a sound down, and the volume up, the volume never changes. Any idea why this is?
 
Thanks, 
  James


      

Re: Calculating normalized patch coords from pixel coords?

[James C. W. <jfc...@ya...>]

I think I understand. Thanks, Christian!
 
-James

--- On Sat, 3/27/10, Christian Walther <cwa...@gm...> wrote:


From: Christian Walther <cwa...@gm...>
Subject: Re: Calculating normalized patch coords from pixel coords?
To: "Content creation for the Pipmak Game Engine" <pip...@li...>
Date: Saturday, March 27, 2010, 12:21 PM


> In order to have a patch work across 3d space, and not be hindered  
> by the seperate cube faces, I wondered if there was a way to  
> calculate, with the 2D coords(e.g. face 1, 342, 567) the equivilent  
> in 3D coords?

Sure, you have everything you need. You can get the pixel dimensions  
of the background face from 'w, h =  
pipmak.getimage("myface.jpeg"):size()', and the geometrical  
arrangement of the face images in 3D space is shown in figures 2 and 3  
in the manual. An edge of the cube is two units in normalized units  
and (w-1) or (h-1) in pixels, which gets you the scale factor, and as  
a fixed point you know that (w/2, h/2) in pixels is (0, 0, -1) in  
normalized coordinates (the center of the face), for face 1, and so on  
for the other faces as shown in figure 2.

  -Christian

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Pipmak-Users mailing list
Pip...@li...
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users



      

Re: Calculating normalized patch coords from pixel coords?

[Christian W. <cwa...@gm...>]

> In order to have a patch work across 3d space, and not be hindered  
> by the seperate cube faces, I wondered if there was a way to  
> calculate, with the 2D coords(e.g. face 1, 342, 567) the equivilent  
> in 3D coords?

Sure, you have everything you need. You can get the pixel dimensions  
of the background face from 'w, h =  
pipmak.getimage("myface.jpeg"):size()', and the geometrical  
arrangement of the face images in 3D space is shown in figures 2 and 3  
in the manual. An edge of the cube is two units in normalized units  
and (w-1) or (h-1) in pixels, which gets you the scale factor, and as  
a fixed point you know that (w/2, h/2) in pixels is (0, 0, -1) in  
normalized coordinates (the center of the face), for face 1, and so on  
for the other faces as shown in figure 2.

  -Christian

Calculating normalized patch coords from pixel coords?

[James C. W. <jfc...@ya...>]

Hi all,
 
In order to have a patch work across 3d space, and not be hindered by the seperate cube faces, I wondered if there was a way to calculate, with the 2D coords(e.g. face 1, 342, 567) the equivilent in 3D coords?
 
Thanks,
  James CW


      

Re: Smoothly rotating to another angle on pano nodes

[James C. W. <jfc...@ya...>]

Hi Christian,
 
Hmmm...Doing that gradually slows it down till it's moving at a crawl. Eventually it reaches the target location, but it takes a while, and looks weird. I think it's because when th code runs every frame, while it avoids panning miscalualtions, it also makes the return value smaller with each run.

--- On Wed, 12/30/09, Christian Walther <cwa...@gm...> wrote:


From: Christian Walther <cwa...@gm...>
Subject: Re: Smoothly rotating to another angle on pano nodes
To: pip...@li...
Date: Wednesday, December 30, 2009, 6:47 AM


James C. Wilson wrote:
> One problem that I've discovered with the 
> "check if current direction ~ target direction and then angle the camera 
> to precisly equal the target" is that if I pan myself while the program 
> is running, the program loses track of where it's going, and hits the 80 
> EL pan limit, slowely spinning on the vertical access. Obviously, to 
> make any of this effective the panorama must be frozen from player 
> control. But since there's not any way to do that yet, I need to use the 
> one that won't hit a dead end, and right now that's the version that 
> checks how many times the function has run...Any suggestions?

Instead of calculating the direction incrementally by adding small steps 
to the current direction, calculate it from scratch in every frame using 
the starting parameters (recorded when you start the animation) and the 
elapsed time (from the first argument of the timer function).

  -Christian


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Pipmak-Users mailing list
Pip...@li...
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users



      

Re: Smoothly rotating to another angle on pano nodes

[Christian W. <cwa...@gm...>]

James C. Wilson wrote:
> One problem that I've discovered with the 
> "check if current direction ~ target direction and then angle the camera 
> to precisly equal the target" is that if I pan myself while the program 
> is running, the program loses track of where it's going, and hits the 80 
> EL pan limit, slowely spinning on the vertical access. Obviously, to 
> make any of this effective the panorama must be frozen from player 
> control. But since there's not any way to do that yet, I need to use the 
> one that won't hit a dead end, and right now that's the version that 
> checks how many times the function has run...Any suggestions?

Instead of calculating the direction incrementally by adding small steps 
to the current direction, calculate it from scratch in every frame using 
the starting parameters (recorded when you start the animation) and the 
elapsed time (from the first argument of the timer function).

  -Christian

Re: Smoothly rotating to another angle on pano nodes

[James C. W. <jfc...@ya...>]

Sorry for the late reply; holidays and all that. 
 
Thanks for the clarifaction. One problem that I've discovered with the "check if current direction ~ target direction and then angle the camera to precisly equal the target" is that if I pan myself while the program is running, the program loses track of where it's going, and hits the 80 EL pan limit, slowely spinning on the vertical access. Obviously, to make any of this effective the panorama must be frozen from player control. But since there's not any way to do that yet, I need to use the one that won't hit a dead end, and right now that's the version that checks how many times the function has run...Any suggestions?
 
Thanks,
  James

--- On Mon, 12/21/09, Christian Walther <cwa...@gm...> wrote:


From: Christian Walther <cwa...@gm...>
Subject: Re: Smoothly rotating to another angle on pano nodes
To: pip...@li...
Date: Monday, December 21, 2009, 4:49 AM


James C. Wilson wrote:
>  >- Why are you putting the parameters into global variables instead of
>  >passing them to the autoPan function as arguments? You could also put
>  >the intermediate results (autoPan_funcCount etc.) into local variables
>  >of the autoPan function, they are visible from the inner function
> Could you tell me how these are done? I can't find any examples in the 
> demo or in Lua refman, maybe I'm looking in the wrong places...
> I tried putting the variables into the function as locals, right inside 
> the function autoPan() declaration, and this works with the default 
> values, but I don't know how to "contact" and alter the state of these 
> while calling the function.

You don't need to "contact" the local variables, you pass the ones you 
need to set from outside as arguments. From inside, they are treated 
indentically to local variables. Like this:

function autoPan(tarAZ, tarEL, time)
   local rate = 0.025
   local iterCount = time/rate
   --...
   pipmak.schedule(
     rate,
     function()
       --do something involving tarAZ, tarEL, time, rate, iterCount, ...
     end
   )
end

and then you call it as

autoPan(270, 4, 1)


  -Christian


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Pipmak-Users mailing list
Pip...@li...
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users



      

Re: Smoothly rotating to another angle on pano nodes

[Christian W. <cwa...@gm...>]

James C. Wilson wrote:
>  >- Why are you putting the parameters into global variables instead of
>  >passing them to the autoPan function as arguments? You could also put
>  >the intermediate results (autoPan_funcCount etc.) into local variables
>  >of the autoPan function, they are visible from the inner function
> Could you tell me how these are done? I can't find any examples in the 
> demo or in Lua refman, maybe I'm looking in the wrong places...
> I tried putting the variables into the function as locals, right inside 
> the function autoPan() declaration, and this works with the default 
> values, but I don't know how to "contact" and alter the state of these 
> while calling the function.

You don't need to "contact" the local variables, you pass the ones you 
need to set from outside as arguments. From inside, they are treated 
indentically to local variables. Like this:

function autoPan(tarAZ, tarEL, time)
   local rate = 0.025
   local iterCount = time/rate
   --...
   pipmak.schedule(
     rate,
     function()
       --do something involving tarAZ, tarEL, time, rate, iterCount, ...
     end
   )
end

and then you call it as

autoPan(270, 4, 1)


  -Christian

Re: Smoothly rotating to another angle on pano nodes

[James C. W. <jfc...@ya...>]

Hi Christian,
 
I improved the inexact rotation issue, it's now exact to the thousandth degree on AZ, and the hundreth on EL. That works for me.
 
>You shouldn't stop your loop when a certain number of iteration is 
>reached, but when the target angles are reached. And you can't count on 
>them being reached exactly, you need to stop once you're close enough 
>(e.g. less than half a step off) and then snap to the correct target value
 
Okay, done.
 
>- Why are you putting the parameters into global variables instead of 
>passing them to the autoPan function as arguments? You could also put 
>the intermediate results (autoPan_funcCount etc.) into local variables 
>of the autoPan function, they are visible from the inner function

Could you tell me how these are done? I can't find any examples in the demo or in Lua refman, maybe I'm looking in the wrong places...
I tried putting the variables into the function as locals, right inside the function autoPan() declaration, and this works with the default values, but I don't know how to "contact" and alter the state of these while calling the function.
 
Thanks, 
   James
--- On Sun, 12/20/09, Christian Walther <cwa...@gm...> wrote:


From: Christian Walther <cwa...@gm...>
Subject: Re: Smoothly rotating to another angle on pano nodes
To: pip...@li...
Date: Sunday, December 20, 2009, 5:22 AM


James C. Wilson wrote:
> Yesterday I realized most of those problems, and fixed them. The new 
> code runs very well, but oddly enough, doesn't return to exactly the 
> defined target location, missing by about 1.5 degrees x, and 0.2 degrees y.

I don't know if that's the whole cause of your deviation, but when you 
add up a lot of little steps like this you can accumulate a lot of 
rounding error. Keep in mind that floating-point numbers such as the 
ones used by Lua have limited precision, and some (most) real numbers 
cannot be represented exactly as floating-point numbers (even if they 
can be represented exactly as decimal numbers, e.g. 0.1). Also, what you 
get back from pipmak.getviewdirection() is not equal in general to what 
you put into pipmak.setviewdirection(), because Pipmak internally stores 
them as single-precision floating-point numbers (corresponding to about 
9 decimal digits), while Lua uses double-precision numbers (about 18 
decimal digits).

You shouldn't stop your loop when a certain number of iteration is 
reached, but when the target angles are reached. And you can't count on 
them being reached exactly, you need to stop once you're close enough 
(e.g. less than half a step off) and then snap to the correct target value.

More comments:

- Why are you putting the parameters into global variables instead of 
passing them to the autoPan function as arguments? You could also put 
the intermediate results (autoPan_funcCount etc.) into local variables 
of the autoPan function, they are visible from the inner function (see 
<http://www.lua.org/manual/5.0/manual.html#visibility>). You should only 
use global variables when you have to, since they make your code less 
encapsulated and harder to maintain - for example, if somewhere else you 
later happen to use the same global variable name for a different 
purpose, that can cause hard to find bugs. (Plus, in Lua, they are less 
efficient than local variables).

> autoPan_rate = 0.025   --the framrate of the rotation, e.g. how many 
> times it runs per second.
- No. That's not the rate, that's the inverse of the rate, how many 
seconds each iteration takes.

- Your timer never stops if autoPan_iterCount happens not to be a whole 
number (autoPan_time isn't a whole multiple of autoPan_rate).


  -Christian


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Pipmak-Users mailing list
Pip...@li...
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users



      

Re: Disabling Panoramic rotation

[Christian W. <cwa...@gm...>]

James C. Wilson wrote:
> Thanks! And where is the feature request tracker? :)

http://sourceforge.net/tracker/?group_id=112801&atid=663295

  -Christian

Re: Smoothly rotating to another angle on pano nodes

[Christian W. <cwa...@gm...>]

James C. Wilson wrote:
> Yesterday I realized most of those problems, and fixed them. The new 
> code runs very well, but oddly enough, doesn't return to exactly the 
> defined target location, missing by about 1.5 degrees x, and 0.2 degrees y.

I don't know if that's the whole cause of your deviation, but when you 
add up a lot of little steps like this you can accumulate a lot of 
rounding error. Keep in mind that floating-point numbers such as the 
ones used by Lua have limited precision, and some (most) real numbers 
cannot be represented exactly as floating-point numbers (even if they 
can be represented exactly as decimal numbers, e.g. 0.1). Also, what you 
get back from pipmak.getviewdirection() is not equal in general to what 
you put into pipmak.setviewdirection(), because Pipmak internally stores 
them as single-precision floating-point numbers (corresponding to about 
9 decimal digits), while Lua uses double-precision numbers (about 18 
decimal digits).

You shouldn't stop your loop when a certain number of iteration is 
reached, but when the target angles are reached. And you can't count on 
them being reached exactly, you need to stop once you're close enough 
(e.g. less than half a step off) and then snap to the correct target value.

More comments:

- Why are you putting the parameters into global variables instead of 
passing them to the autoPan function as arguments? You could also put 
the intermediate results (autoPan_funcCount etc.) into local variables 
of the autoPan function, they are visible from the inner function (see 
<http://www.lua.org/manual/5.0/manual.html#visibility>). You should only 
use global variables when you have to, since they make your code less 
encapsulated and harder to maintain - for example, if somewhere else you 
later happen to use the same global variable name for a different 
purpose, that can cause hard to find bugs. (Plus, in Lua, they are less 
efficient than local variables).

> autoPan_rate = 0.025   --the framrate of the rotation, e.g. how many 
> times it runs per second.
- No. That's not the rate, that's the inverse of the rate, how many 
seconds each iteration takes.

- Your timer never stops if autoPan_iterCount happens not to be a whole 
number (autoPan_time isn't a whole multiple of autoPan_rate).


  -Christian

Re: saveequirect not working

[Christian W. <cwa...@gm...>]

armylegend wrote:
> I sure appreciate your quick reply, went to sleep and woke up with a message
> (I'm coming off of a year tour in Iraq in a couple weeks so it's 8 am here). 

Two hours difference to me in Switzerland.

> Everything is as you said, I checked every folder I thought it could be in
> except the one it was.  Apparently spotlight doesn't search for files inside
> the pipmak packages either.  I've got a (what I think is funny) screen shot
> of spotlight not finding a file right in front of me :confused:.  

I think Spotlight is not meant to search inside packages, since users 
aren't supposed to put their files there (and well-behaved applications 
shouldn't either - one more point that makes this a dirty hack).

>     I'm not going to have much time on the computer for about a month but as
> soon as I get back I'd like to help with this project in any way I can.  If
> that just means making all the frustrating mistakes and putting them in the
> wiki so others don't, that's something.  Thanks for helping me out here,
> once I get rolling maybe I can actually get to some of the stuff on the "to
> do" list.  

That would be great. For my part, with my previous project just finished 
(<http://mystonline.com/forums/viewtopic.php?t=18880>), I intend to 
spend some time on Pipmak too over the holidays and hopefully get a new 
release out.

> P.S. Maybe I've read it wrong, but handles have to be rectangular correct? 

Yes (in spherical coordinates).

> If so, the process of making them isn't the frustrating part, it's making
> them work the way I want that seems like it'd be frustrating.

If you have a use case for which the rectangularity (or anything else) 
is a major obstacle, we can always discuss it and maybe find a better 
solution.

  -Christian

Re: saveequirect not working

[armylegend <chi...@ho...>]

I sure appreciate your quick reply, went to sleep and woke up with a message
(I'm coming off of a year tour in Iraq in a couple weeks so it's 8 am here). 
Everything is as you said, I checked every folder I thought it could be in
except the one it was.  Apparently spotlight doesn't search for files inside
the pipmak packages either.  I've got a (what I think is funny) screen shot
of spotlight not finding a file right in front of me :confused:.  
    I'm not going to have much time on the computer for about a month but as
soon as I get back I'd like to help with this project in any way I can.  If
that just means making all the frustrating mistakes and putting them in the
wiki so others don't, that's something.  Thanks for helping me out here,
once I get rolling maybe I can actually get to some of the stuff on the "to
do" list.  

thanks, 
Phil

P.S. Maybe I've read it wrong, but handles have to be rectangular correct? 
If so, the process of making them isn't the frustrating part, it's making
them work the way I want that seems like it'd be frustrating.  I'm probably
wrong of course.  

>You are aware that you can reload the node while it's running in
Pipmak and immediately see the edited hotspots, right?

Absolutely, Pipmak's ability to edit while running is a huge plus in my
book, I was attempting to find a way around repainting and reloading as
getting hotspots on anything above 50ish degrees elevation seems the least
forgiving. 

Mac didn't want me to find it.  Should have used the spotlight inside the
package contents, oy.
http://old.nabble.com/file/p26861233/Picture%2B4.jpeg   
-- 
View this message in context: http://old.nabble.com/saveequirect-not-working-tp26858533p26861233.html
Sent from the pipmak-users mailing list archive at Nabble.com.