pipmak-users — Content creation for the Pipmak Game Engine

[Pipmak-Users] Compiler

[qp <dn...@ra...>]

I'm sorry but have pipmak a compile function for creating EXE file?
-- 
View this message in context: http://www.nabble.com/Compiler-tf3808911.html#a10780117
Sent from the pipmak-users mailing list archive at Nabble.com.

Re: [Pipmak-Users] Patch rotation proposal

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

Andrea Viarengo wrote:
> Probably, I not understand what you mean when speaking about setting
> the anchor point, 
> 
> I have understand that we could set anchor in 2 manners:
> 
> 1) {...,anchorx=x, anchory=y,...}
>    2 coordinates relatives to the image (2d space)
> 
> or
> 
> 2) {..., anchor=(nx,ny,nz), ...}   
>    or better:
>    {..., anchor_nx=nx, anchor_ny=ny, anchor_nz=nz, ...}
>    
>    3 coordinates relative to main coordinates system (3d space) 
>    centralized on the center of the cube. 
> 
> Have I understood correctly?

Apparently not. There's no anchor_nx etc., only anchorx and anchory, and 
they designate a point in the patch plane, measured in patch pixels from 
the top left corner of the patch image. Maybe we should call these 
coordinates something other than "x" and "y" to distinguish them from 
the background image pixel coordinates (x, y) and normalized 3D 
coordinates (nx, ny, nz), since they live in a completely different 
space. Maybe "h", "v" for horizontal and vertical? "r", "d" for right 
and down? Any ideas?

Let me try to explain it differently: First, you choose a point on the 
patch image, by setting anchorx and anchory. You can imagine the patch 
to be located at the origin or anywhere else at this time. Then, you 
grab the patch by that point and move it to location (x, y) in 
background pixel coordinates, or to location (nx, ny, nz) in normalized 
3D coordinates.

> The Cpu usage *rise* to 85% when pipmak is in the background
> and *fall* to 5-10% when pipmak go to foreground. 
> 
> I'm using Windows XP on my notepad
> 
> On the desktop that I have at home (Windows XP with Nvidia N6600)
> the Pipmak's cpu usage alway stay under 10% also in the background.

Then that's probably just a deficiency of the notebook nVidia driver, 
and there's likely nothing we can do to get proper vertical retrace 
synchronization even in the background. Just to suppress the excessive 
CPU usage though, we could monitor the frame rate and insert some sleeps 
when it goes above, say, 120 FPS.

> I've tryed to install pipmak on an "OLD" Linux machine (CPU=600MHz)
> with RedHat 9.0 and a matrox G400 as graphic card
> just to test performance,
> but I always get the message:
> 
> Xlib: extension "XFree86-DRI" missing on display ":0.0"

No idea how to fix that - I'm not very familiar with getting OpenGL to 
work on Linux on various hardware. Does the same thing happen when you 
start glxgears?

> ../pipmak: relocation error: ./pipmak: undefined symbol: SDL_RWFromConstMem
> ...
> SDL-1.2.5-3

SDL 1.2.5 is a bit old - SDL_RWFromConstMem was introduced in SDL 1.2.7 
(and the current version is 1.2.11). If you're compiling yourself and 
can't get a newer SDL, you could try to replace the calls to it by 
SDL_RWFromMem.

> Probably this machine is too old to run pipmak, what do you think about?

Shouldn't be. I want Pipmak to run at least on anything that has 
hardware OpenGL. Last time I tried, it even worked relatively well (even 
though slow) in software rendering on Mac OS X on a 266 MHz PPC G3 and 
on Windows 98 in QEMU on an 867 MHz PPC G4.

  -Christian

Re: [Pipmak-Users] Patch rotation proposal

[Andrea V. <and...@gm...>]

Christian Walther <cwalther <at> gmx.ch> writes:

> 
> Andrea Viarengoa wrote:
> > I'm a little confused about set anchorx=anchory=0.5 to make a patch
> > to coincide with a cube face, can you explain better?
> (.....)

Ok, I understand now.

> 
> > If I use the notation (nx,ny,nz), I could set an anchor that doesn't 
> > lie on the same plane on which the patch image lie.
> 
> I don't understand what you mean by that. The anchor by definition 
> always lies in the plane of the patch. It need not lie in the plane of a 
> cube face, but that's what we want.
> 

Probably, I not understand what you mean when speaking about setting
the anchor point, 

I have understand that we could set anchor in 2 manners:

1) {...,anchorx=x, anchory=y,...}
   2 coordinates relatives to the image (2d space)

or

2) {..., anchor=(nx,ny,nz), ...}   
   or better:
   {..., anchor_nx=nx, anchor_ny=ny, anchor_nz=nz, ...}
   
   3 coordinates relative to main coordinates system (3d space) 
   centralized on the center of the cube. 

Have I understood correctly?

Yes, the anchor by definition must lies in the plane of the patch,
but what prevent the user to set (nx,ny,nz) everywhere 
in the 3D space, and also in a point does not belong to the plan?

For example:
my patch lie on plane ny=1, so the plane is represented by (nx,1,nz)
I could set, in a next rotation operation:

  anchor=(0,-1,0) 

i.e.: 

  anchor_nx=0, anchor_ny=-1, anchor_nz=0 

This point doesn't belong to the plane of my patch,
But, this couldn't be a problem if I rotate the patch around the line 
orthogonal to the plane which connect the plane itself and the anchor point.
(and this line always exist...)

 
> 
> Just to get the language straight - does the CPU usage rise *by* 5% (to 
> 85%) or *fall* to 5%?
>

I apologize for my bad English,

The Cpu usage *rise* to 85% when pipmak is in the background
and *fall* to 5-10% when pipmak go to foreground. 
 
> with the overlapping windows. On what platform is this?

I'm using Windows XP on my notepad

On the desktop that I have at home (Windows XP with Nvidia N6600)
the Pipmak's cpu usage alway stay under 10% also in the background.

I've tryed to install pipmak on an "OLD" Linux machine (CPU=600MHz)
with RedHat 9.0 and a matrox G400 as graphic card
 
just to test performance,

but I always get the message:

Xlib: extension "XFree86-DRI" missing on display ":0.0"
./pipmak: relocation error: ./pipmak: undefined symbol: SDL_RWFromConstMem

I have installed the driver for the video card and enabled DRI in 
XF86Config, and log tell me that Driver and DRI are loaded successfully
In fact, in the file /var/log/Xfree86.0.log I can found:

.......
(II) Loading extension Xfree86-DRI
(II) LoadModule: "mga"
(II) Loading /usr/X11R6/lib/modules/drivers/mga_drv.o
(II) Module mga: vendor="Matrox Graphics Inc. - x86_32 - release v4.4.0
      compiled for 4.3.0, module version = 1.1.0
.......

I have also installed these rpm package:

SDL-1.2.5-3
SDL_image-1.2.2-5
SDL-ttf-2.0.6-0
openal-0.0.8

Probably this machine is too old to run pipmak, what do you think about?

Bye

Andrea

Re: [Pipmak-Users] Patch rotation proposal

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

Andrea Viarengoa wrote:
> I'm a little confused about set anchorx=anchory=0.5 to make a patch
> to coincide with a cube face, can you explain better?

This is related to the following two facts:

- The cube face images don't extend exactly to the cube edge but half a 
pixel beyond. This is explained under "Making Cubic Panoramas" in 
section 2.8 of the reference.

- For a similar reason (seamless bilinear interpolation), a margin of 
half a pixel is cut off each edge of a patch, so that the visible part 
of the patch ends at the centers of the outermost pixels. This is hinted 
at (though not properly explained) in the last paragraph of section 2.9 
"Patches".

By setting the anchor to (0.5, 0.5), i.e. the center of the corner 
pixel, we place that pixel at the same position (centered on the cube 
corner) as the corner pixel of the cube face.

> When you speak about putting anchorx,anchory at (x,y),
> I understand that you refer to the relative coordinates of the image,
> is it correct?

Exactly.

> If I use the notation (nx,ny,nz), I could set an anchor that doesn't 
> lie on the same plane on which the patch image lie.

I don't understand what you mean by that. The anchor by definition 
always lies in the plane of the patch. It need not lie in the plane of a 
cube face, but that's what we want.

> About the performance, the behaviour is strange, because I have notice 
> that also with a traditional pipmak project (like MyHouse Tour), 
> sometime on my notebook the rotation along the azimuth is jerk, sometime no.

I sometimes see this behavior as well, but so far I never bothered to 
find out what causes it and if it can be fixed in Pipmak.

> Another strange things: if I put the pipmak window in the background, 
> pipmak eat over 80% of cpu time and when I put in the foreground,
> the cpu amount rise to 5%, if I leave pipmak in the background for a lot
> of time without do nothing, I have to kill because take 100% of cpu time.
> Do you think this behaviour depend by my graphic card? 

Just to get the language straight - does the CPU usage rise *by* 5% (to 
85%) or *fall* to 5%?

Pipmak is supposed to render (at most) one frame per screen refresh 
(i.e. 60 frames per second on usual LCDs). If that limitation works, it 
should not use excessive amounts of CPU time. If for some reason it 
doesn't, Pipmak renders as fast as it can and takes all available CPU 
time. Could be that the limitation works when the Pipmak window is in 
the foreground and OpenGL can render directly to the frame buffer, but 
not when the window is partially obscured and needs to be composited 
with the overlapping windows. On what platform is this?

  -Christian

Re: [Pipmak-Users] Patch rotation proposal

[Andrea V. <and...@gm...>]

Hello Christian, 

I think the use of anchorx,anchory was a good ideas, 
I was thinking at a same thing.

I'm a little confused about set anchorx=anchory=0.5 to make a patch
to coincide with a cube face, can you explain better?

When you speak about putting anchorx,anchory at (x,y),
I understand that you refer to the relative coordinates of the image,
is it correct? 

If I use the notation (nx,ny,nz), I could set an anchor that doesn't 
lie on the same plane on which the patch image lie.
What's happen in this case?
Do You think to get (x,y) with a orthogonal projection on lying plane?

About patches that extend beyond their face, I was speaking about 
the actual behaviour, I known that the arbitrary patches placement
will resolve all this situation, it was just a curiosity, 
overall about the random clipping.

About the performance, the behaviour is strange, because I have notice 
that also with a traditional pipmak project (like MyHouse Tour), 
sometime on my notebook the rotation along the azimuth is jerk, sometime no.

Another strange things: if I put the pipmak window in the background, 
pipmak eat over 80% of cpu time and when I put in the foreground,
the cpu amount rise to 5%, if I leave pipmak in the background for a lot
of time without do nothing, I have to kill because take 100% of cpu time.
Do you think this behaviour depend by my graphic card? 
(Nvidia quadro4 500 GoGL a particular model don't cover by Nvidia normal
drivers - so my drivers are update to year 2002 and doesn't exist more
updated drivers)

Bye 

Andrea

Re: [Pipmak-Users] Wiki spam (was: Patch rotation proposal)

[Urs H. <ur...@an...>]

Christian Walther wrote:
> Andrea Viarengo wrote:
>> P.S.: There are a lot of spams on your wiki pages...you can see if you
>> click on "recent changes"
>> You have to think some way to prevent these abuses...
> 
> As long as the spammers were clueless enough to use their own pages
> (that weren't even reachable from the main page), I didn't see a big
> problem with this. But you're right that they have started to vandalize
> real pages now - thanks for reporting.

I can't believe it. They fill mailinglists and newsgroups with spam and now,
they even do that with wiki pages. I am sure it won't take long until they
create accounts with random usernames. Gaah!

Re: [Pipmak-Users] Wiki spam (was: Patch rotation proposal)

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

Andrea Viarengo wrote:
> P.S.: There are a lot of spams on your wiki pages...you can see if you
> click on "recent changes"
> You have to think some way to prevent these abuses... 

As long as the spammers were clueless enough to use their own pages 
(that weren't even reachable from the main page), I didn't see a big 
problem with this. But you're right that they have started to vandalize 
real pages now - thanks for reporting.

I just disallowed anonymous editing (you now need to create an account 
to be able to edit pages), let's see how long that keeps them out.

  -Christian

Re: [Pipmak-Users] Patch rotation proposal

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

Andrea Viarengo wrote:
> Yes, you are on right about patch rotation that isn't very simple
> to use...

OK, how about this:

- We introduce another pair of parameters, "anchorx" and "anchory", that 
specify, in patch pixels, a point on the patch. By default, they will be 
set to (0, 0), i.e. the top left corner of the image. This anchor point 
will be placed at (x, y) or (nx, ny, nz) and will be the center of rotation.

- nw specifies the visible width of the patch, which is one pixel 
smaller than its image width (w) due to the half pixel cut off each side 
for interpolation. Likewise for nh.

So, to make a patch coincide with a cube face (assuming it has the same 
image size), you would specify anchorx = anchory = 0.5 and nw = nh = 2. 
To rotate a patch around its center, set anchorx and anchory to half its 
width and height.

Everything should also work on slides and panels if we specify that 
normalized coordinates are equal to pixel coordinates there (that's 
actually what happens internally, as of revision 152).

> About patches, 
> I've notice that if you place a patch across two faces, or better,
> you place a patch that goes beyond the edge of the face
> (i.e. face is 640x640, and you put a patch 100x100 at x=600)
> the part of the patch that fall in another face is cut in a 
> randomly way, and it varies based on the azimuth angle of the view.
> 
> Is this an intentional behavior? 

In a way, yes. You weren't supposed to make patches that extend beyond 
their face up to now. What happens is that parts of the patch fall 
behind the camera's far clipping plane, which lies just outside of the 
cube. This will change, because for arbitrary patch placement, this 
plane needs to be moved farther away anyway.

> Or it would not be better crop the part of the patch 
> that it exceeds the edge of the face?

That wouldn't work too well with the arbitrary placement stuff we're 
discussing, would it? Being able to place patches outside of the cube is 
basically the whole point...

> If I put a lot of patches (beyond 800), I've notice, in slower computer,
> that the rotation around the azimuth angle, sometime it goes in jerks.
> 
> You think that I could reduce jerks if I reduce the dimensions (in bytes)
> of the patches? Or 800 patches is really too-many patches?  

There are certainly some things that could be optimized in Pipmak in 
this regard - I just never did it because for normal cases the 
performance always seemed good enough to me. Honestly, at this time 800 
patches is not what I see as the primary use case of Pipmak that I'd 
spend a lot of optimization effort on.

Unless your 800 patches all use different images, so that you fill up 
video memory and the OpenGL renderer starts paging them out to main 
memory, I wouldn't expect reducing the size to make a difference. Of 
course, it's hard to tell where the performance bottleneck is without 
doing any actual profiling.

  -Christian

Re: [Pipmak-Users] =?utf-8?q?Patch_rotation_proposal_=28was=3A_Autocu?= =?utf-8?q?bic=3A_my=09reply_to_C=2EWalther=29?=

[Andrea V. <and...@gm...>]

Ciao Christian,

Don't worry about the delay,
as you can see, also I am not on time!
In this period in Italy there are a lot of holiday (25/4, 1/5)
and the other days I've worked in a military company, 
where I cannot connect to the Internet.

You are right about my aproximate explanation,
I wrote those while I was making other five things, so I haven't
double checked what I have written....

All your objections are right.

Probably you are little less rusted than me with trigonometrical calculations.

But, apart my errors, I think that the important thing was that 
you have understood very well what I had in mind.

I am in agreement with you on specify angles in degrees,
and set the value of k to "2".

Yes, you are on right about patch rotation that isn't very simple
to use...I will try to think something else.

About the slides, I think that these are used to represent just
2D drawing, so thetax e thetay should be not influential, and only "angle"
works to permit to rotate patches (in a more simple way than 3D patches...)
I'm perplexed about using normalized coordinates on slides, 
because are typical of 3D space, and I don't known if they could be
useful on slide...you could permits the use of normalized coords 
just only on cubic panoramas.

About patches, 
I've notice that if you place a patch across two faces, or better,
you place a patch that goes beyond the edge of the face
(i.e. face is 640x640, and you put a patch 100x100 at x=600)
the part of the patch that fall in another face is cut in a 
randomly way, and it varies based on the azimuth angle of the view.

Is this an intentional behavior? 
Or it would not be better crop the part of the patch 
that it exceeds the edge of the face?

If I put a lot of patches (beyond 800), I've notice, in slower computer,
that the rotation around the azimuth angle, sometime it goes in jerks.

You think that I could reduce jerks if I reduce the dimensions (in bytes)
of the patches? Or 800 patches is really too-many patches?  

Thank you.

Ciao.

Andrea

P.S.: There are a lot of spams on your wiki pages...you can see if you
click on "recent changes"
You have to think some way to prevent these abuses... 

Re: [Pipmak-Users] Patch rotation proposal (was: Autocubic: my reply to C.Walther)

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

Hello Andrea, I've finally gotten around to have a look at your=20
proposal. Sorry for the delay, I've been busy with other stuff.

> Using normalized coordinates, the method that could permit to place a p=
atch
> in the 3D space would be something like:
>=20
>   patch {
>     nx=3Dnx
>     ny=3Dny
>     nz=3Dnz
>     nw=3Dnw
>     nh=3Dnh
>     thetax=3Dtx
>     thetaz=3Dtz
>     angle=3Dangle
>     image=3Dimage
>     [visible=3Dvisible]
>     ....
>     }

OK, sounds good.

> these angles are expressed in radiants

I'd rather specify angles in degrees, because that's the way it's done=20
everywhere else in Pipmak, and I guess it's what non-scientists are more =

familiar with. Any objection?

> so if nx0,ny0,nz0 is the point of the upper-left corner of the patch
> and nx1,ny1,nz1 is the point of lower-right corner of the patch:
>=20
> nx1=3Dnx0+nw*cos(thetaz)
> ny1=3Dny0+nw*sin(thetaz)-nh*sin(thetax)
> nz1=3Dnz0-nh*cos(thetax)

Are you sure about this? Unless I made a mistake, I think there's=20
something wrong. If you insert nw =3D nh =3D 1 and thetax =3D thetaz =3D =
pi/2,=20
you get (nx1, ny1, nz1) =3D (nx0, ny0, nz0), i.e. the patch is squished t=
o=20
zero length along its diagonal.

> some example:
> =20
> patch {
>        nx=3D-0.5,ny=3D0.5,nz=3D0.5,
>        nw=3D1,nh=3D1,
>        thetax=3D0,thetaz=3D0,
>        image=3Df.png
>       }
>=20
>   this put an image that fully cover face1
>   notice that nw=3D1 and nh=3D1 stretch the image to full cover the cub=
e face
>   nw=3D0.5 and nh=3D0.5 will put an image that cover just one quadrant =
of the face. =20
>=20
>   the lower-right corner is placed on nx=3D0.5,ny=3D0.5,nz=3D-0.5
>=20
> patch {
>        nx=3D0.5,ny=3D0.5,nz=3D-0.5,
>        nw=3D1,nh=3D1,
>        thetax=3D0,thetaz=3D0,
>        angle=3Dpi,
>        image=3Df.png
>       }
>=20
>   this put the same image turned upside down=20
>   notice that the upper-left corner of the patch is placed
>   on the lower-right corner of the face1=20

This doesn't match with how you described the axis directions before.=20
 From this example, I'd conclude x =3D east, y =3D north, z =3D up (x and=
 y=20
swapped).

> patch {
>        nx=3D-0.5,ny=3D1,nz=3D0.5,
>        nw=3D1,nh=3D1,
>        thetax=3D0,
>        thetaz=3D0,
>        image=3Df.png
>       }
>=20
>   this put an image centered in the middle of the face1
>   which is the projection of a square parallel to face1 but double dist=
ant.

OK.

> patch {
>        nx=3D-0.5,ny=3D-0.5,nz=3D0.5,
>        nw=3D1,nh=3D1,
>        thetax=3D0,thetaz=3Dpi/2,
>        image=3Df.png
>       }
>=20
>   this put an image that fully cover the face6=20

Can't follow this - if the axes are the same as in the previous examples =

(or even your original description), and the patch is rotated about the=20
point (nx, ny, nz), I'd say it now lies in the plane of face 3, 4, or 5=20
(depending on the definition of thetaz), not on face 6. If the z axis=20
now points down, OK (and then thetaz seems to describe a rotation around =

the -x axis).


In short, because of these contradictions, I'm unable to conclude how=20
exactly you define thetax and thetaz. Therefore, I'm going to describe=20
my own version of what I think you have in mind:

First, let me make some of the arbitrary choices you made differently,=20
in order to better match what's done internally (if you think that your=20
choices were not arbitrary, but have a reason behind them, please say so)=
:

- For normalizing the coordinates, I chose k =3D 2, not k =3D 1, i.e. the=
=20
cube faces are at +-1 (not +- 0.5).

- Coordinate axes:
   x in direction of face 2 (east), away from face 4
   y in direction of face 5 (up), away from face 6
   z in direction of face 3 (south), away from face 1

How the patch is rotated:

- The upper left corner of the patch is located at (nx, ny, nz).

- The patch starts out oriented parallel to face 1, with its upper right =

corner in direction +x and lower left corner in direction -y from the=20
upper left corner (nx, ny, nz). The "inward-pointing" normal of the=20
patch points in direction +z.

- First, it is rotated by <thetax> around its top edge (oriented=20
rightward, i.e. positive angles move the center of the patch in=20
direction -z).

- Then, it is rotated by <thetay> around its (already rotated) left edge =

(oriented upward, i.e. positive angles move the center of the patch in=20
opposite direction to its normal).

- Lastly, it is rotated by <angle> around its normal at the top left corn=
er.

Reproducing your examples (and a few more) with this:

- patch that covers face 1:

patch {
	nx =3D -1, ny =3D 1, nz =3D -1,
	nw =3D 2, nh =3D 2,
	thetax =3D 0, thetay =3D 0, angle =3D 0,
	...
}

- patch that covers face 1, upside down:

patch {
	nx =3D 1, ny =3D -1, nz =3D -1,
	nw =3D 2, nh =3D 2,
	thetax =3D 0, thetay =3D 0, angle =3D 180,
	...
}

- patch that covers face 6, in the "natural" orientation of this face:

patch {
	nx =3D -1, ny =3D -1, nz =3D -1,
	nw =3D 2, nh =3D 2,
	thetax =3D -90, thetay =3D 0, angle =3D 0,
	...
}

- patch that lies in the plane of face 6, but moved northwards so that=20
it appears as a trapezium at the bottom of face 1:

patch {
	nx =3D -1, ny =3D -1, nz =3D -3,
	nw =3D 2, nh =3D 2,
	thetax =3D -90, thetay =3D 0, angle =3D 0,
	...
}

- patch that covers face 4 (in its natural orientation):

patch {
	nx =3D -1, ny =3D 1, nz =3D 1,
	nw =3D 2, nh =3D 2,
	thetax =3D 0, thetay =3D 90, angle =3D 0,
	...
}

- two versions of a patch that covers face 2, rotated 90=B0 clockwise fro=
m=20
its natural orientation:

patch {
	nx =3D 1, ny =3D 1, nz =3D 1,
	nw =3D 2, nh =3D 2,
	thetax =3D 90, thetay =3D -90, angle =3D 0,
	...
}
patch {
	nx =3D 1, ny =3D 1, nz =3D 1,
	nw =3D 2, nh =3D 2,
	thetax =3D 0, thetay =3D -90, angle =3D -90,
	...
}

Is this about what you had in mind?


> if you want rotate a patch placed on face1 respect his center,
> I have to rotate and translate the patch
>=20
> patch:moveto(0,0,-nh,0,0,pi/2).

Are you sure it's that easy? In fact that's the main point I'm unsure=20
about how to solve in a user-friendly way.

In the system I proposed above, rotating a patch on face 1 whose=20
unrotated top left corner lies at (nx, ny, -1) by angle theta=20
(counterclockwise) around its center would look like

patch:moveto(nx + nw/2 - nw/2*cos(theta) - nh/2*sin(theta),
	ny - nh/2 - nw/2*sin(theta) + nh/2*cos(theta),
	-1,
	0, 0, theta).

Substituting nx =3D ny =3D 0 and theta =3D 90=B0 as in your example, that=
's still

patch:moveto(nw/2 - nh/2, -nh/2 - nw/2, -1, 0, 0, 90).

Somehow I'm not quite happy with this.


> I'm little perplexed about
> normalization of w and h, but we could use original size (in pixels) of=

> the patch if we don't know the dimension in pixel of the cube
> (which could be whichever value because it's a projection)

I think offering an "nw" and "nh" property for normalized width/height,=20
as you did, is a good idea. After all, you don't need to use it, you can =

still specify width and height in pixels using the existing "w" and "h"=20
properties if you want. (The only question is, how big is a pixel in=20
normalized units if the cube faces have different pixel sizes? Maybe=20
just take the value from face 1.)


Another question that we haven't touched yet is, what do we do on=20
slides? At least the "angle" property should work there too. Using=20
normalized coordinates is probably not that good an idea, as they are=20
non-uniform if the slide is not a square.


Thanks for your input!

  -Christian

Re: [Pipmak-Users] Autocubic: my reply to C.Walther

[Andrea V. <and...@gm...>]

Hi Christian, 

> If you'd like to help make this happen, could you propose a 
> specification of how you'd imagine this to work? What methods or 
> parameters would be added, and what would they exactly do? 

I've tried to image how could be the methods that could permit to collocate
corners of a patch in the space and also rotate it

So we I have make this theory:

1) We have to put 4 points (everyone with 3 coordinates) in a 3D space.

2) These points must lie on the same plane arbitrary oriented in the space,
otherwise patch will be deformed in a not-plane surface that I think become
difficult to manage.

3) The point 0,0,0 is collocated at center of the cube and in this point 
is collocated the view point (my eyes...)

4) Where is it placed the face number 1 of my cube? 
   (I'm refer to figure 2 on page 10 of your doc)

   face 1 (azimuth=0)  : x0=-k/2,y0=+k/2,z0=+k/2 
                         x1=+k/2,y1=+k/2,z1=+k/2
                         x2=-k/2,y2=+k/2,z2=-k/2
                         x3=+k/2,y3=+k/2,z3=-k/2

   but which is the value of k?
   I cannot determine this value...if I use an image that covers completely  
   the face 1, and this patch has dimensions 512x512, k could be 512,
   but if I use an image 300x300, k could be 300....

   Therefore, or I set the value of "k", or I have to normalize the 
   coordinates respect k which is the dimension of my cube.

   Now you use azimuth/elevation/width/height  to specify some area
   (like handle), we could add the zenith to specify points and area in the
   3D space, but I think this would be a little complex to manage 
   from the Users point of view, I think that would be more simplex
   to use the normalized coordinates.

Using normalized coordinates, the method that could permit to place a patch
in the 3D space would be something like:

  patch {
    nx=nx
    ny=ny
    nz=nz
    nw=nw
    nh=nh
    thetax=tx
    thetaz=tz
    angle=angle
    image=image
    [visible=visible]
    ....
    }

where 

nx,ny,nz  are the normalized coordinates of the location in the space 
of the upper-left corner of the image 
and this is the starting point of the drawing of the patch.

nw,nh are the normalized dimensions of the image (respect k) 

thetax,thetaz  are the angles of the plane on which the patch lies
along axis x,z and respect axis z,x 
(are sufficient 2 angles), these angles are expressed in radiants

angle is the rotation angle (expressed in radiants) of the patch 
respect the line orthogonal to the plane on which the four corners lie
and centered in the normalized point specified with nx,ny,nz 
(upper-left corner) 

so if nx0,ny0,nz0 is the point of the upper-left corner of the patch
and nx1,ny1,nz1 is the point of lower-right corner of the patch:

nx1=nx0+nw*cos(thetaz)
ny1=ny0+nw*sin(thetaz)-nh*sin(thetax)
nz1=nz0-nh*cos(thetax)

(I have set angle=0 in this formula, because the full formula is more
complex...)

some cases:

nx=1  identified the plane which lie the face1 of the cube
nx=-1 identified the plane which lie the face3 of the cube
ny=1  identified the plane which lie the face2 of the cube
ny=-1 identified the plane which lie the face4 of the cube
nz=1  identified the plane which lie the face5 of the cube
nz=-1 identified the plane which lie the face6 of the cube

some example:
 
patch {
       nx=-0.5,ny=0.5,nz=0.5,
       nw=1,nh=1,
       thetax=0,thetaz=0,
       image=f.png
      }

  this put an image that fully cover face1
  notice that nw=1 and nh=1 stretch the image to full cover the cube face
  nw=0.5 and nh=0.5 will put an image that cover just one quadrant of the face.  

  the lower-right corner is placed on nx=0.5,ny=0.5,nz=-0.5

patch {
       nx=0.5,ny=0.5,nz=-0.5,
       nw=1,nh=1,
       thetax=0,thetaz=0,
       angle=pi,
       image=f.png
      }

  this put the same image turned upside down 
  notice that the upper-left corner of the patch is placed
  on the lower-right corner of the face1 
 
patch {
       nx=-0.5,ny=1,nz=0.5,
       nw=1,nh=1,
       thetax=0,
       thetaz=0,
       image=f.png
      }

  this put an image centered in the middle of the face1
  which is the projection of a square parallel to face1 but double distant.

patch {
       nx=-0.5,ny=-0.5,nz=0.5,
       nw=1,nh=1,
       thetax=0,thetaz=pi/2,
       image=f.png
      }

  this put an image that fully cover the face6 

patch {
       nx=-0.5,ny=0.5,nz=0.5,
       nw=1,nh=1,
       thetax=0,thetaz=pi/2,
       image=f.png
      }

  this put a patch parallel to face6, but I can see his projection on
  face1 as a trapezium


of course I could have also the method:

patch:moveto(nx,ny,nz, thetax,thetaz, angle)

so

patch:moveto(0,0,0,0,0,pi/2)  rotate the image of 90° respect the upper-left 
corner

if you want rotate a patch placed on face1 respect his center,
I have to rotate and translate the patch

patch:moveto(0,0,-nh,0,0,pi/2).


I'm not analize all the aspect of these methods, I'm little perplexed about
normalization of w and h, but we could use original size (in pixels) of
the patch if we don't know the dimension in pixel of the cube
(which could be whichever value because it's a projection)

I don't know if this is the best and the simplex method to do this,
but it's a starting point to start a discussion about it.
What do you think about?

Bye.

Andrea

Re: [Pipmak-Users] Autocubic: my reply to F.Pistonesi and C.Walther

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

Fabrizio Pistonesi wrote:
> Is a problem if a change Pipmak Windows executable icon?

No, that's perfectly OK. In fact, I'd encourage it.

  -Christian

Re: [Pipmak-Users] Autocubic: my reply to C.Walther

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

Andrea Viarengo wrote:
> While you will be on the way, if it isn't too difficult to implement,=20
> would be useful (of course... for my target, but probably
> could be useful also for other people)
> another function which able to cut a region inside a patch
> using another picture like a mask (which could be only black and white)=
=2E..
> and the region cut will become transparent.=20
> (off course the patch must be a PNG).

Cutting rectangular holes into images is already possible using the=20
image manipulation support that's currently in SVN (but not in an=20
official release yet). Using other images as masks is not possible yet,=20
but it seems like a good idea. I'll think about it.

> Would be useful also the opposite, i.e.: the possibility of use the
> discarded region: imagine that I make a picture with all the=20
> alphabetic letters inside, I could make a function that write some text=

> on a layer cutting the letters directly from that picture...
> I could change font just changing the picture...=20

I'm not sure you'd still need that when you have the text rendering=20
support that's currently in SVN...

> And what you think about possibility to arbitrary rotate a patch...
> (for now pipmak give us the possibility to flip a patch using
> negative width and height)
> useful for realize some instrumentation like pressure meters, compass,
> clocks and other tools equipped with pointers...

Yes, I agree. I also thought about that when Stefan Gro=DFhauser posted=20
his "Z=FCndapp Underground" - he uses a few pre-rotated images, but being=
=20
able to rotate a patch would probably make things easier and better-looki=
ng.

Of course you'll already be able to do this "by hand" with the arbitrary =

patch corner placement, but a way of specifically setting rotation would =

certainly be useful.

If you'd like to help make this happen, could you propose a=20
specification of how you'd imagine this to work? What methods or=20
parameters would be added, and what would they exactly do? I think=20
finding a nice user interface for this is already half the work, and it=20
can't hurt to have several people take part in the design process -=20
actually implementing it should be quite simple afterwards. This is just =

OpenGL, after all, which doesn't care whether the textured triangles we=20
tell it to render are rotated or not.

  -Christian

Re: [Pipmak-Users] Autocubic: my reply to F.Pistonesi and C.Walther

[Fabrizio P. <fpi...@li...>]

> Fabrizio Pistonesi wrote:
> > however i found enough time to make a small ehm... short (it's 40Mb!)=
 demo:
> > 
> > http://rapidshare.com/files/23847719/EternitY_DEMO_-0.1_engine-0.2.6.=
zip.html
> > 
> > let me know about problems.
> 
> Very nice! A few random comments, if you're after criticism (I see that=
 
> many things are obviously unfinished, so you may already be aware of th=
em):
> 
> - The lighting in the shaded areas of the railway station and in the 
> house doesn't do justice to the nice modeling. You seem to be using jus=
t 
> a constant ambient term, which makes everything look very flat. You 
> really need more light sources in these areas, perhaps shadowless, or a=
 
> global illumination simulation (radiosity or whatever).
> 

The station is the first scene that I've modeled and have a lot of proble=
m (the train is out of the rail for example and the left area use lens gl=
are as post-processing image effect) but has several billion of polygon s=
o is very hard to modify and re-render. Currently I'm using Vue, it allow=
 to model wonderful landskapes but not very well other things


> - Elena talks too fast for me! :) Considering that I've never learnt 
> Italian, it takes me longer to understand what she says than the text 
> stays visible in the terminal... The upcoming text output support shoul=
d 
> help you improve this.

Yes I know, I'm planning to use an image as subtitle but I've to decide w=
ith my team mates what she have to say, however is not important. She say=
 something as: "Hello, I'm Elena. My grand talked a lot to me about you. =
Now I will bring you at home so you can leave your stuff and rest" and in=
 the house:"your room is the last on the right. take a look around if you=
 want"
 
> - I was really surprised when I saw your method of using 
> hotspot-palette.gif as a hotspot map for navigation in the house. Is 
> that intended as a temporary hack or as a permanent solution?

I had this idea from the Andrea's autocubic demo, it increase incredibly =
the work; is a good for large areas but not for small ambients like house=
. 


> - I assume you haven't asked Cyan before taking their sounds? You shoul=
d 
> do that as soon as possible if you continue to publish previews of your=
 
> work that contain them.
> 
>   -Christian

No, in facts... I've only used some sound to make this ambiensts a little=
 more alive but i will ask if I still use this sounds.
by the way, I've noticed the errors messages but I haven't check the uppe=
r/lower case...

Now I've realized the "Main garden" with "Temple on the water" sections,w=
ith the lens glare effect the pictures seems too blurred however I'm not =
a programmer or 3d graphic designer;
unfortunately the other zones is not ready: one, because the terrain is n=
ot rendered (!?) and the waterfall, because host a puzzle. If you want to=
 see I can release it anyway!

p.s.
Is a problem if a change Pipmak Windows executable icon?

Greetings, Fabrizio.=0A=0A=0A--------------------------------------------=
----------=0APassa a Infostrada. ADSL e Telefono senza limiti e senza can=
one Telecom=0Ahttp://click.libero.it/infostrada=0A

Re: [Pipmak-Users] Autocubic: my reply to C.Walther

[Andrea V. <and...@gm...>]

Christian Walther <cwalther <at> gmx.ch> writes:

Hi Chris!

> I wouldn't spend too much thought or work on this at this time. I expect 
> allowing arbitrary placement of patch corners in 3D to be quite simple 
> to implement, so I'd wait for that. I'm not making any promises, but 
> maybe I'll have a go at it over the easter weekend.

Wow, if you will add this function to pipmak would be wonderful!!

Can I expose to you some other ideas?
 
While you will be on the way, if it isn't too difficult to implement, 
would be useful (of course... for my target, but probably
could be useful also for other people)
another function which able to cut a region inside a patch
using another picture like a mask (which could be only black and white)...
and the region cut will become transparent. 
(off course the patch must be a PNG).

I try to explain better with an example:

Imagine that I have a picture of a wall, and I want to put a door in 
the middle, I need a method to make an hole...otherwise I need two pictures,
One without hole and another with ..

Would be useful also the opposite, i.e.: the possibility of use the
discarded region: imagine that I make a picture with all the 
alphabetic letters inside, I could make a function that write some text
on a layer cutting the letters directly from that picture...
I could change font just changing the picture... 

And what you think about possibility to arbitrary rotate a patch...
(for now pipmak give us the possibility to flip a patch using
negative width and height)
useful for realize some instrumentation like pressure meters, compass,
clocks and other tools equipped with pointers...
(I'm thinking to vary enigmas could be found in the Myst saga...)    

Well, I don't know how could be complex implement these because I don't 
know which type of primitive functions are put on hand by SDL Library..

Ok,Ok, don't worry, these are only ideas...

You can estimate better than me if it is the case to introduce
these functionalities, or not, 
and which of these would have the precedence,
or if before it's better spent time to improve other parts of Pipmak..
   
If you implement just a single function to allow arbitrary placement
of patch corners in 3D could be sufficient and very usefull for me.

Thank you very much and Happy Easter!!! 

Ciao e Buona Pasqua!!

P.S.: Don't work too much, rests a little also, the Holidays are important!!

Re: [Pipmak-Users] Autocubic: my reply to C.Walther

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

Andrea Viarengo wrote:
> For this reason I need a true method to deform an image,
> 
> Otherwise to avoid the defect I have to pre-make all the possible trapezial
> distortion of every textured image...
> 
> Do you have any other idea to make this?

I wouldn't spend too much thought or work on this at this time. I expect 
allowing arbitrary placement of patch corners in 3D to be quite simple 
to implement, so I'd wait for that. I'm not making any promises, but 
maybe I'll have a go at it over the easter weekend.

  -Christian

Re: [Pipmak-Users] Autocubic: my reply to F.Pistonesi and C.Walther

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

Fabrizio Pistonesi wrote:
> however i found enough time to make a small ehm... short (it's 40Mb!) demo:
> 
> http://rapidshare.com/files/23847719/EternitY_DEMO_-0.1_engine-0.2.6.zip.html
> 
> let me know about problems.

Very nice! A few random comments, if you're after criticism (I see that 
many things are obviously unfinished, so you may already be aware of them):

- The lighting in the shaded areas of the railway station and in the 
house doesn't do justice to the nice modeling. You seem to be using just 
a constant ambient term, which makes everything look very flat. You 
really need more light sources in these areas, perhaps shadowless, or a 
global illumination simulation (radiosity or whatever).

- Elena talks too fast for me! :) Considering that I've never learnt 
Italian, it takes me longer to understand what she says than the text 
stays visible in the terminal... The upcoming text output support should 
help you improve this.

- I was really surprised when I saw your method of using 
hotspot-palette.gif as a hotspot map for navigation in the house. Is 
that intended as a temporary hack or as a permanent solution?

- I assume you haven't asked Cyan before taking their sounds? You should 
do that as soon as possible if you continue to publish previews of your 
work that contain them.

  -Christian

Re: [Pipmak-Users] Autocubic: my reply to F.Pistonesi and C.Walther

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

Andrea Viarengo wrote:
> I'm not investigate too much,but I believe this depends on the "case" 
> (lower/upper) of the filename, i.e.: the application search a file
> called "glow.ogg", but the file is named "Glow.ogg"

Good point. I just added a note about this to the reference manual.

I noticed the error messages too, but I just attributed them to the fact 
that I was using the original Pipmak (and a development version at that) 
to play the game instead of the included version.

  -Christian

Re: [Pipmak-Users] Autocubic: my reply to F.Pistonesi and C.Walther

[Andrea V. <and...@gm...>]

Fabrizio Pistonesi <fpistonesi <at> libero.it> writes:

Hi Fab,

Thank you!!
I have downloaded your demo!

The rendering of the railway station is very nice, 
I think the design of it it take you long time to do!
Which programs do you have used to do that?

I notice for now just a little problem:
When I run EthernitY using the pipmak zipped file as you provide,
the application cannot found sounds,
but, if I dezip "EternitY.pipmak" in a folder the problem seems to disapear.

I'm not investigate too much,but I believe this depends on the "case" 
(lower/upper) of the filename, i.e.: the application search a file
called "glow.ogg", but the file is named "Glow.ogg",
Windows should be case-insensitive, but pipmak was developed on Unix
platform which is case-sensitive.

You must check the name of the files in your application, 
The better thing would be that you always use the name of the file
written with the same case (lowercase) in the OS and inside the lua file.
Remember that Windows is a little bastard and the first time that you 
create a file, it try to put the first letter Uppercase and the next 
lowercase...you have to modify after.
This is also important to permit the execution of your game in the 
other Pipmak platforms (Linux and macosX).

Ciao!!

Andrea

Re: [Pipmak-Users] Autocubic: my reply to F.Pistonesi and C.Walther

[Andrea V. <and...@gm...>]

Hi Christian, 

I try to reply....if I cannot to do this, I will contact gmane administrators.

> the doors sometimes look a bit skewed, 
> is that a bug?

Yes, the problem is that I cannot distort a square into a trapezium,
but I have divided the trapezium into two triangle and one rectangle
and after I distort them...you can see it as an approximation...
This phenomenon is more visible on all horizontal lines,
and disappear on vertical line (which remain vertical...)

I've just upload a new version that it use textures for walls and floors
(It's more heavier than previous: 6 MByte because the png)
I've added also the possibility of show a map as an overlay.   

There are still a lot of things to do, but I am quite satisfied,
Now I the graphics is a little better than semi-3D games of our infancy...
isn't it? 

You can see the defect that you have noted overall on the external 
bricks wall, and on the skirting board in the rooms.
     
For this reason I need a true method to deform an image,

Otherwise to avoid the defect I have to pre-make all the possible trapezial
distortion of every textured image...

Do you have any other idea to make this?

Ciao

Andrea

Re: [Pipmak-Users] Autocubic: my reply to F.Pistonesi and C.Walther

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

Andrea Viarengo wrote:
> I do Know why, but I cannot manage to Reply to the thread
> "Re: File IO with Pipmak and image manipulation."
> Gmane continue to tell me: 
> "You seem to be top-posting. Don't do that."
> .....(Are there some bugs in gmane? )

If you're sure that you are not top-posting (and you're sure that the 
rejection comes from Gmane), I'd recommend reporting that to the Gmane 
admins. If it does not come from Gmane but from SourceForge, send me a 
copy of your message and of the rejection notice, and I'll see if this 
is something I can change in the mailing list configuration. It's not my 
intention to police people into not top-posting using an overzealous 
automatic filter.

> I've update the demopack on my site, now it's possible to see throw the
> door holes, and every room can have their different floor and ceil and
> outside you could see mountain around...

Nice! I noticed that the tops of the doors sometimes look a bit skewed, 
is that a bug?

> About the possibility of using the Pipmak's existing saved game functionality,
> I haven't investigate about it, could be interesting workaround,
> but pipmak state are saved in a binary or in a lua mode, 
> so I could read using dofile?

The files are binary (and the Lua code that reads and writes them is in 
the "serialize" and "deserialize" functions in Pipmak 
Resources/resources/defaults.lua or at 
<http://pipmak.svn.sourceforge.net/viewvc/pipmak/trunk/pipmak/extras/serialize.lua?view=markup>). 
But that shouldn't matter to you as you don't have to read them 
yourself, Pipmak does that for you. When you load a saved game, you just 
get the contents of the "state" table restored to what they were when 
the game was saved.

> How I can add some external image manipulation, using loadlib()?

I'm not sure if that's the easiest way. The image manipulation support 
in Pipmak is not designed to be modular, so it would probably be easier 
to add things directly to Pipmak than in a plugin. As for how it works, 
have a look at pipmakLuaLib.c (and images.h, images.c), particularly the 
bits added in 
<http://pipmak.svn.sourceforge.net/viewvc/pipmak?view=rev&revision=145>.

  -Christian

Re: [Pipmak-Users] Autocubic: my reply to F.Pistonesi and C.Walther

[Fabrizio P. <fpi...@li...>]

Hello,
Thank you Andrea, for now I'm going on with the rendering.
however i found enough time to make a small ehm... short (it's 40Mb!) dem=
o:

http://rapidshare.com/files/23847719/EternitY_DEMO_-0.1_engine-0.2.6.zip.=
html

let me know about problems.=0A=0A=0A-------------------------------------=
-----------------=0ALeggi GRATIS le tue mail con il telefonino i-mode=99 =
di Wind=0Ahttp://click.libero.it/imode=0A

[Pipmak-Users] Autocubic: my reply to F.Pistonesi and C.Walther

[Andrea V. <and...@gm...>]

Hello to all pipmakers!

I do Know why, but I cannot manage to Reply to the thread
"Re: File IO with Pipmak and image manipulation."
Gmane continue to tell me: 
"You seem to be top-posting. Don't do that."
....(Are there some bugs in gmane? )

So I post here my replies to Fabrizio and Christian

1) Here there is my reply to Fabrizio Pistonesi:
---------------------------------------------------------------------------

Hi Fab,

Thank you for the compliments.

The problem is that who write an adventure game cannot play to own game
because he know all the secrets!! 
So, my target should be to generate a complete pseudo-random adventure
with casual (but not to much) world (a very far target...)!

I saw the shots of your game: Wow!! I'm waiting to play with this!! 
I would like to help you very much, if I had much time!!!
Thanks for your proposal, perhaps more ahead I will be able give to you 
some my small contribution...for the moment I cannot guarantee it to you.


I know what you mean with "harder"... 

Into the mouth of the wolf with EternitY!!!

(Yes, it's a bad traslation of an idiomatic italian, but I think you can
understand!!
For the english speaking people: "Break a leg!!" )

Ciao
Andrea 
-----------------------------------------------------------------------------	 
2) Here there is my reply to Christian:

Thank you, Chris

Yes, the graphics now is very simple...but I hope to improve it.
Now every surface can be a texture, but 
the great problem are the shadows, because they can help much
the perspective view and the perception of the depth...I'm working on it 
(perhaps using overlay patch with alpha!=1)

I've update the demopack on my site, now it's possible to see throw the
door holes, and every room can have their different floor and ceil and
outside you could see mountain around...

About the possibility of using the Pipmak's existing saved game functionality,
I haven't investigate about it, could be interesting workaround,
but pipmak state are saved in a binary or in a lua mode, 
so I could read using dofile?
 
How I can add some external image manipulation, using loadlib()?

Bye,

Andrea

Re: [Pipmak-Users] Play "cut Scenes"

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

Wenzler, Thomas wrote:
> Since the Pipmak engine is not capable of playing Movies ort he like at=
=20
> the moment, would it be possible to launch some external Application=20
> from Pipmak to handle =93cut scenes=94 ?

The current shipping Pipmak binaries don't include the Lua "os" library, =

so you can't launch any external programs (unless you compiled that=20
library into a loadable module and loaded it with "loadlib" - that=20
should work, I think).

A similar thing has been proposed for sound at one time, see=20
<http://thread.gmane.org/gmane.games.devel.pipmak.user/63/focus=3D64>.

> Or is this a possible security hazard beause you don=92t know what kind=
 of=20
> Application is launched to handle the Movieplaying?

That's the main motivation for not including the "os" library. Of=20
course, it's debatable whether this is a good reason, since a finished=20
game is supposed to include Pipmak, and the authors can compile whatever =

they want into the version of Pipmak they ship.

  -Christian

Re: [Pipmak-Users] Play "cut Scenes"

[Fabrizio P. <fpi...@li...>]

Hello Thomas,
for this purpose i've tryed to render a sequenche of jpeg files with a pr=
ogressive number as name instead .avi and i've used pipmak.schedule() fun=
ction to play this sequence into a patch. 
I hope it was clear.

Regards, Fabrizio


> Dear Christian,
> 
>  
> 
> Since the Pipmak engine is not capable of playing Movies ort he like at=

> the moment, would it be possible to launch some external Application
> from Pipmak to handle "cut scenes" ?
> 
> Or is this a possible security hazard beause you don't know what kind o=
f
> Application is launched to handle the Movieplaying?
> 
>  
> 
> Best Regards
> 
>  
> 
> Thomas
> 
> =0A=0A=0A------------------------------------------------------=0APassa=
 a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom=0Ahttp=
://click.libero.it/infostrada=0A