gdalgorithms-list

[Algorithms] Leafy BSP Tree Contruction

[Manolache A. <pro...@ya...>]

             During the bsp tree compilation there happens sometimes that a polygon
would be split so much until it becomes very thin with an area almost
0. This polygon would further be split and thus obtaining degenerate
triangles. The problem is that the construction fails when fed this
kind of polygons and full leaves(all polygons used as splitter) arive
in back nodes. When clipping triangles or classifying them i used a
small epsilon to compare to 0(absolute tolerance test). How can i go around avoiding
degenerate triangle creation, how can these be handled? Is it the sole
duty of the artist to avoid such cases?


      

[Algorithms] Per-Vertex interpolation of cubemap(cube with 6 different textures), through intersection of reflectionrays(3x)

[<mr_...@gm...>]

Hello,

(don't know, wether the [Algorithms] must be in subject field, if no, 
sorry for doublepost)
I have the following problem:
I have an 3d-object, witch is surrounded with a cube(boundingbox) on the 
different sites a textures of the envoirment, like cubemapping. But 
solong I understand, in OpenGL/Direct3D the procedery works on 
per-Pixel. Where the reflectionvectors where calculated and are 
interpolated(the vectors for self). But my problem is, that I don't want 
to use these per-pixel way, and go per-vertex(not with the actual ray, 
but with the texturecoordinates of ray-with-cube-intersections). Are 
there some reports or ideas how to archive this? Or this mathmaticaly 
impossible?

Thanks for any suggestions. And sorry for the bad english, hope it's 
still understandable.

Maxim

Re: [Algorithms] Multiuser synch

[Danny K. <dr...@we...>]

> Danny Kodicek wrote:
>> Actually, what I'm running is a science simulation, and because it needs 
>> to
>> be deterministic (or as near as we can make it) we do tie it in with the
>> frame rate. It's more important that they're synched than that they have
>> smooth physics experiences.
>>
>
> If you want it to be deterministic, you absolutely need a fixed time step.

This is kind of going off-topic and I suspect that we're using different 
words for the same thing. My point is that the physics isn't tied to real 
time at all, time is simply measured in frames. It is a fixed time step, in 
the sense that as long as two people run for the same number of frames, at 
the end they will be in the same position (however long it takes in real 
time)

Danny 

Re: [Algorithms] Multiuser synch

[Jon W. <jw...@gm...>]

Danny Kodicek wrote:
> Actually, what I'm running is a science simulation, and because it needs to
> be deterministic (or as near as we can make it) we do tie it in with the
> frame rate. It's more important that they're synched than that they have
> smooth physics experiences.
>   

If you want it to be deterministic, you absolutely need a fixed time step.

Sincerely,

jw

Re: [Algorithms] Left-handed vs. right-handed

[Eric H. <eri...@gm...>]

Thanks for all the replies. Yes, I should mention something about loop
reversal (I was tempted to in the original post, but it was getting quite
long as it was). I'm planning to try to unify some camera parameters in our
own system, so thanks, Patryck, for the pointer to the Eberly document
http://www.geometrictools.com/Documentation/LeftHandedToRightHanded.pdf.

On Thu, May 7, 2009 at 10:31 AM, Graham Hazel <gra...@ge...>
 wrote:

> The fundamental truth is that for boring technical reasons certain
> drivers/APIs make it more convenient to use certain basis
> representations.  So yes, at some point some competent person has to
> specify which basis to use for each target platform.


I guess I'd like to know more about the boring details that make it more
convenient to go with one basis or another - we don't have to clutter the
list with this (it's not truly algorithmic), but I'd be interested if you'd
be willing to email me. Do you just mean the built-in calls like glFrustum?
Or something else? I did find this in Jeff Weeks' documentation, which
mentions one old fixed-function lighting feature of OpenGL that forces -Z to
be used. I thought I'd include the note here in full, as it's relevant.

---------------------
Appendix:  My two programming idiosyncracies.
---------------------
OpenGL Conventions

   For the most part OpenGL's conventions are simple and elegant.
   However, my conventions differ from OpenGL's in two major ways.

   Matrices (... column-major discussion deleted...)

   Coordinate Systems

       OpenGL orients projection space with the observer
       looking down the positive z-axis, with with x-axis
       pointing to the right and the y-axis pointing up.
       However, OpenGL forces no assumptions about the orientation
       of world space;  the programmer is free to choose
       his/her coordinate system and projection matrix
       however s/he wishes.  So far so good.

       The only complication is that the OpenGL documentation adopts
       the unfortunate convention of looking down the negative z-axis,
       and requiring that the projection matrix invert the z-axis when
       passing from world to projection space.  The motivation for this
       convention, as far as I can tell, was to use a right-handed
       coordinate system ("like mathematicians use") in world space.
       (Computer scientists seem to have suffered from a bit of
       an inferiority complex back in the early days, or at least needed
       to convince people that their work was intellectually rigorous.)
       Fortunately the negative z-axis convention appears only in the
       documentation and in certain helper functions like glFrustum(),
       but otherwise is not forced on us.  [One other exception is
       that when you turn off GL_LIGHT_MODEL_LOCAL_VIEWER, OpenGL
       assumes the viewer is looking from infinity down the negative z-axis,
       and there seems to be no way to change that assumption.]

       Within this program, we adopt the convention that

           the x-axis points to the right
           the y-axis points up
           the z-axis points forward

       in world space as well as projection space.

Eric

Re: [Algorithms] Left-handed vs. right-handed

[Graham H. <gra...@ge...>]

The fundamental truth is that for boring technical reasons certain
drivers/APIs make it more convenient to use certain basis
representations.  So yes, at some point some competent person has to
specify which basis to use for each target platform.  This information
can live in an exporter script, or in asset processing code somewhere.

Of course there are a few gory details in the asset conversion itself
that I'm conveniently glossing over, but morally that's the whole extent
of how much you have to care.

Compare this to your original suggestion:

> Which one of the driver multitude of possible drivers and APIs? Even
if you are single-platform-single-API and if you
> adapt everything to "The One API" you use now, few years from now you
may have to adapt the same codebase to a different
> platform/API. I'd bet you are safer sticking to the winding (or
chirality, call it all you want) that _you_ prefer, and be
> prepared to convert signs and windings on every interfacing point with
any external API. It's not _that_ much of a hassle,
> as long as you are clear on what you use internally.

YMMV, but for me that is a lot of unnecessary hassle.

Graham


-----Original Message-----
From: Alen Ladavac [mailto:ale...@cr...] 
Sent: 07 May 2009 14:46
To: Graham Hazel
Cc: Game Development Algorithms
Subject: Re: [Algorithms] Left-handed vs. right-handed

Graham wrote at 5/7/2009:
> I don't understand your other objection though.  When the user presses
> "forward" I just ask my camera class which way forward is :-).

Then it's the camera. But some piece of code, or content has to know
it. Granted, you can make things like "which way is front", "which way
is up" and "which way is north" configurable in the game's tools and
you can make games with different basis. But it is the same thing.
Whether you fix a basis in the code, or the artists determine it in
the tools (once for each game), you still have to decide on one,
right?

Alen

Re: [Algorithms] Left-handed vs. right-handed

[Graham H. <gra...@ge...>]

Yes, you're right about the reflections: I should have said "you want to
avoid dealing with more reflections than you have to".  I think the
argument still applies---by the time your data is transformed to the
run-time representation the only reflections should be the ones the
artists have asked for.  That way you can detect them and flip the sense
of forward and back faces as necessary.  This will work independently of
the basis representation.

I don't understand your other objection though.  When the user presses
"forward" I just ask my camera class which way forward is :-).

Graham



-----Original Message-----
From: Alen Ladavac [mailto:ale...@cr...] 
Sent: 07 May 2009 13:27
To: Graham Hazel
Cc: Game Development Algorithms
Subject: Re: [Algorithms] Left-handed vs. right-handed

Graham wrote at 5/7/2009:
> Now, my contention is that at run-time you want to avoid having to
deal
> with reflections: SO(3) is much nicer than O(3).  Given that
> requirement, the assumptions implicit in whatever driver/API is
> underneath may make your choice of basis for you.
Erm, wrong requirement. You _want_ to be able to deal with reflections
at run time. I mean - its easier for me not to, but the artists need
it - so it has to be that way. Stretches that are not multiples of
identity and even those involving different signs on different axes
are here to stay, for us at least.

> The key is to make all your own code basis-agnostic.  This is easy if
> you have no preference!

You can, and should, make majority of your code basis-agnostic.
Internals of math, physics, lighting, etc. can be agnostic. But you
cannot do it at the points of interfacing with the reality. When the
user presses movement stick on the gamepad forward, you have to choose
to map it to -Z, +Z, -Y, +Y, whatever... Same way when you want to
output something on the screen, you have to know which of the axes in
your internal representation is "front", which is "right" etc. and
have to adjust your output to match the basis used by the rendering
API.

Cheers,
Alen

Re: [Algorithms] Left-handed vs. right-handed

[Alen L. <ale...@cr...>]

Graham wrote at 5/7/2009:
> I don't understand your other objection though.  When the user presses
> "forward" I just ask my camera class which way forward is :-).

Then it's the camera. But some piece of code, or content has to know
it. Granted, you can make things like "which way is front", "which way
is up" and "which way is north" configurable in the game's tools and
you can make games with different basis. But it is the same thing.
Whether you fix a basis in the code, or the artists determine it in
the tools (once for each game), you still have to decide on one,
right?

Alen

Re: [Algorithms] Left-handed vs. right-handed

[Alen L. <ale...@cr...>]

Graham wrote at 5/7/2009:
> Now, my contention is that at run-time you want to avoid having to deal
> with reflections: SO(3) is much nicer than O(3).  Given that
> requirement, the assumptions implicit in whatever driver/API is
> underneath may make your choice of basis for you.
Erm, wrong requirement. You _want_ to be able to deal with reflections
at run time. I mean - its easier for me not to, but the artists need
it - so it has to be that way. Stretches that are not multiples of
identity and even those involving different signs on different axes
are here to stay, for us at least.

> The key is to make all your own code basis-agnostic.  This is easy if
> you have no preference!

You can, and should, make majority of your code basis-agnostic.
Internals of math, physics, lighting, etc. can be agnostic. But you
cannot do it at the points of interfacing with the reality. When the
user presses movement stick on the gamepad forward, you have to choose
to map it to -Z, +Z, -Y, +Y, whatever... Same way when you want to
output something on the screen, you have to know which of the axes in
your internal representation is "front", which is "right" etc. and
have to adjust your output to match the basis used by the rendering
API.

Cheers,
Alen

Re: [Algorithms] Undershooting in spherical harmonics generatedbycubemap convolution

[Jarkko L. <al...@gm...>]

FWIW, radially symmetric SH is called zonal harmonics.


Cheers, Jarkko


-----Original Message-----
From: Alen Ladavac [mailto:ale...@cr...] 
Sent: Thursday, May 07, 2009 1:50 PM
To: Sam Martin
Cc: Game Development Algorithms
Subject: Re: [Algorithms] Undershooting in spherical harmonics
generatedbycubemap convolution

Sam wrote at 5/6/2009:
> It really is just a scalar - this is one of the very cool things
> about SH. When represented in SH, the blurry version is just a
> scaled version of the non-blurry version. This is true when
> convolving against any radially symmetric function. The radially
> symmetic bit effectively means the result doesn't depend on the
> m-components of the function, and turns into just one scalar for
> each L.

Ah, scalar _per band_! Yes, that makes sense. I originally thought you
ment scaling all the factors by the same scalar, which sounded weird.

> You should think of the L-bands in SH as frequencies.

Indeed. I somehow skipped over that part. It makes the whole concept
much easier to digest. :)

Thanks,
Alen


----------------------------------------------------------------------------
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Undershooting in spherical harmonics generated bycubemap convolution

[Alen L. <ale...@cr...>]

Sam wrote at 5/6/2009:
> It really is just a scalar - this is one of the very cool things
> about SH. When represented in SH, the blurry version is just a
> scaled version of the non-blurry version. This is true when
> convolving against any radially symmetric function. The radially
> symmetic bit effectively means the result doesn't depend on the
> m-components of the function, and turns into just one scalar for
> each L.

Ah, scalar _per band_! Yes, that makes sense. I originally thought you
ment scaling all the factors by the same scalar, which sounded weird.

> You should think of the L-bands in SH as frequencies.

Indeed. I somehow skipped over that part. It makes the whole concept
much easier to digest. :)

Thanks,
Alen

Re: [Algorithms] Multiuser synch

[Danny K. <dr...@we...>]

Hi, Jon 
 
> First, you need to run physics at a fixed rate everywhere, 
> not tie it to 
> the graphics frame rate. See 
> http://www.b500.com/~hplus/graphics/game_loop.html for example.

Actually, what I'm running is a science simulation, and because it needs to
be deterministic (or as near as we can make it) we do tie it in with the
frame rate. It's more important that they're synched than that they have
smooth physics experiences.

> 
> Second, you probably want to use the lock-step network sync 
> method. See 
> the "1,500" archers article for a great introduction: 
> http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_2
88_network_.php
> 
> Once that's done, if you still have questions, you may want 
> to check out 
> the FAQ for Multiplayer and Networking over at gamedev.net; 
> it has more 
> networking and multiplayer references (all the way from 
> basics, through 
> classics, to avant-garde): 
> http://www.gamedev.net/community/forums/showfaq.asp?forum_id=15

Thanks for these references, that's really helpful. It's always hard to know
where to look (although I should have thought of trying gamasutra and
gamedev)

Best
Danny

Re: [Algorithms] Left-handed vs. right-handed

[Graham H. <gra...@ge...>]

I haven't explained myself very well, so let me try to be more specific.

In my way of thinking I have to change neither my code nor my data.
What I do have to change is the _representation_ of my data.  My world
has a bunch of vectors and transformations in it.  Mathematically
speaking, these do not start life with an intrinsic coordinate
representation---it's only once you've picked a coordinate frame that
you can evaluate basis functions and write down some numbers.  It's
worth remembering that you've made a choice and done some work here.
(The fact that they're called Cartesian coordinates should help you
remember that once upon a time this was not a trivial idea.)

Unfortunately, computers are good at numbers and bad at abstraction,
which means that to do anything useful at all you have to pick a basis
before you start.  This is a Bad Thing.  Typically, picking a basis is
the last thing you want to do---ask anyone who's had to write down a
bunch of proofs in linear algebra.

Now, my contention is that at run-time you want to avoid having to deal
with reflections: SO(3) is much nicer than O(3).  Given that
requirement, the assumptions implicit in whatever driver/API is
underneath may make your choice of basis for you.  This is fine---just
transform the representation of your data and away you go.  Everything
will still work---clockwise is still clockwise since it's well-defined
in your world, independently of the coordinate representation.

The key is to make all your own code basis-agnostic.  This is easy if
you have no preference!

Graham



-----Original Message-----
From: Alen Ladavac [mailto:ale...@cr...] 
Sent: 06 May 2009 12:32
To: Graham Hazel
Cc: Game Development Algorithms
Subject: Re: [Algorithms] Left-handed vs. right-handed

Graham wrote at 5/6/2009:
> Since it's clearly "correct" to be agnostic, I prefer to work with
> the chirality that the graphics driver expects.

Which one of the driver multitude of possible drivers and APIs? Even
if you are single-platform-single-API and if you adapt everything to
"The One API" you use now, few years from now you may have to adapt
the same codebase to a different platform/API. I'd bet you are safer
sticking to the winding (or chirality, call it all you want) that
_you_ prefer, and be prepared to convert signs and windings on every
interfacing point with any external API. It's not _that_ much of a
hassle, as long as you are clear on what you use internally.

JM2C,
Alen

Re: [Algorithms] Multiuser synch

[Jon W. <jw...@gm...>]

Danny Kodicek wrote:
> We're developing an online demo system within our software that allows one
> user (the 'shepherd') to take control of a group of other computers (the
> 'sheep'). It's important that the software remains in synch, otherwise the
> actions the shepherd takes may not replicate correctly. So what we need is a
> simple one-way synch algorithm.
>   

First, you need to run physics at a fixed rate everywhere, not tie it to 
the graphics frame rate. See 
http://www.b500.com/~hplus/graphics/game_loop.html for example.

Second, you probably want to use the lock-step network sync method. See 
the "1,500" archers article for a great introduction: 
http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php

Once that's done, if you still have questions, you may want to check out 
the FAQ for Multiplayer and Networking over at gamedev.net; it has more 
networking and multiplayer references (all the way from basics, through 
classics, to avant-garde): 
http://www.gamedev.net/community/forums/showfaq.asp?forum_id=15

Hope this helps!

Sincerely,

jw

Re: [Algorithms] Left-handed vs. right-handed

[Jon W. <jw...@gm...>]

Ruben Penalva wrote:
> In my honest opinion, this is the same with "column major vs row 
> major". Whatever you choose just stick with it. Make a clear 
> documentation about your choose and how are you going to convert the 
> data to your system. Then, forget about it and never ever change the 
> decision you made. :)


Hey, how about "row vector on left" vs "column vector on right" ? Or 
"WXYZ" vs "XYZW" quaternions?

However, it turns out that if you're mainly D3D, you end up with 
left-handed, row major, row vectors on the left, and if you're mainly 
OpenGL, you end up with right-handed, column-major, column vectors on 
the right, and because you flip both the storage and the multiplication 
convention, the in-memory representation turns out to be the same, which 
confuses people even more, because they don't even realize that they're 
mixing and matching code from different conventions, and it "mostly" 
works anyway.

Sincerely,

jw

Re: [Algorithms] Undershooting in spherical harmonics generated bycubemap convolution

[Sam M. <sam...@ge...>]

Hi Alen,

<snip>
Am I wrong to think that the difference is not just a scaler in some
of those cases? When trying to get irradiance SH from a cubemap which
represents radiance, I'm convolving not just by the SH, but also by
clamped cosine. When convolving with cosine, I'm effectively
generating a "blurry" SH from a "non-blurry" cubemap. Converting that
"blurry" SH into a cubemap will generate a "blurry" cubemap, which
cannot be easily compared to the "non-blurry" original (save for doing
O(P^2) convolution in the cubemap space and comparing to that).
</snip>

It really is just a scalar - this is one of the very cool things about SH. When represented in SH, the blurry version is just a scaled version of the non-blurry version. This is true when convolving against any radially symmetric function. The radially symmetic bit effectively means the result doesn't depend on the m-components of the function, and turns into just one scalar for each L. Incidentally, the fact all the odd bands from L3 upwards disappear is the main proof you can't invert this convolution - it does actually lose information. 

You should think of the L-bands in SH as frequencies. When you convolve with the clamped cosine you remove a load of high frequencies - but not all due to the presence of the clamp. So when you blur your SH version of the cubemap all you need to do is scale the frequencies appropriately. (This scaling is the A terms in the paper).  

<snip>
That passes. But it seems like (and is intuitive to be that way) this
kind of test covers only existence of correct x/y/z powers in the
polynomials. Putting any coefficients in front passes the test. (E.g.
if c0-c4 are all 1, this test passes.) Or am I missing something?
</snip>

Providing you test each coefficient in isolation, sure, it only tests that something else isn't getting into your code causing 'talk' between the coefficients. Testing you haven't made a mistake with the scaling is harder.

Cheers,
Sam

Re: [Algorithms] Multiuser synch

[Danny K. <dr...@we...>]

Sorry, tiny correction:
 
> If they're less than 5 frames behind, they run a bit faster than the
> shepherd (if they can)

I meant a bit slower, of course

Danny

[Algorithms] Multiuser synch

[Danny K. <dr...@we...>]

Hi there

I'm trying to implement a fairly simple algorithm but it's proving difficult
to get right, and I wondered if there is a standard method that I don't know
about.

We're developing an online demo system within our software that allows one
user (the 'shepherd') to take control of a group of other computers (the
'sheep'). It's important that the software remains in synch, otherwise the
actions the shepherd takes may not replicate correctly. So what we need is a
simple one-way synch algorithm.

What we're currently doing is this:
The shepherd tries to run at the standard frame rate. Every frame, it
broadcasts its (attempted) frame rate to the sheep.
If the sheep are within a certain range (5-25 frame behind), they use the
same frame rate as the shepherd.
If they're less than 5 frames behind, they run a bit faster than the
shepherd (if they can)
If they're less than 0 frames behind, they pause
If they're more than 25 frames behind, they try to run as fast as they can,
and they tell the shepherd.
If the shepherd knows that some sheep are lagging behind, it starts to slow
down
Otherwise it starts to speed up


This is working pretty well, but we're getting quite a lot of 'bunjee'
effects (hysteresis, I guess it would be called), where instead of settling
to a reasonably stable speed, it's slowing down and speeding up alternately.
Also when the shepherd is running slower than the sheep, it's proving
difficult to stop the lag getting below 0.

Like I say, I'm sure this is a common problem with a standard algorithm -
anyone know, or have any suggestions about improvements to my existing
system?

Best
Danny

Re: [Algorithms] Left-handed vs. right-handed

[Patryck P. <pat...@ya...>]

See article http://www.geometrictools.com/Documentation/LeftHandedToRightHanded.pdf

Regards,

--- Em qua, 6/5/09, Alen Ladavac <ale...@cr...> escreveu:

> De: Alen Ladavac <ale...@cr...>
> Assunto: Re: [Algorithms] Left-handed vs. right-handed
> Para: "Graham Hazel" <gra...@ge...>
> Cc: "Game Development Algorithms" <gda...@li...>
> Data: Quarta-feira, 6 de Maio de 2009, 8:31
> Graham wrote at 5/6/2009:
> > Since it’s clearly “correct” to be agnostic, I
> prefer to work with
> > the chirality that the graphics driver expects.
> 
> Which one of the driver multitude of possible drivers and
> APIs? Even
> if you are single-platform-single-API and if you adapt
> everything to
> "The One API" you use now, few years from now you may have
> to adapt
> the same codebase to a different platform/API. I'd bet you
> are safer
> sticking to the winding (or chirality, call it all you
> want) that
> _you_ prefer, and be prepared to convert signs and windings
> on every
> interfacing point with any external API. It's not _that_
> much of a
> hassle, as long as you are clear on what you use
> internally.
> 
> JM2C,
> Alen
> 
> 
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY
> circumstances! Your
> production scanning environment may not be a perfect world
> - but thanks to
> Kodak, there's a perfect scanner to get the job done! With
> the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with
> all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
> 


      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

Re: [Algorithms] Left-handed vs. right-handed

[Alen L. <ale...@cr...>]

Graham wrote at 5/6/2009:
> Since it’s clearly “correct” to be agnostic, I prefer to work with
> the chirality that the graphics driver expects.

Which one of the driver multitude of possible drivers and APIs? Even
if you are single-platform-single-API and if you adapt everything to
"The One API" you use now, few years from now you may have to adapt
the same codebase to a different platform/API. I'd bet you are safer
sticking to the winding (or chirality, call it all you want) that
_you_ prefer, and be prepared to convert signs and windings on every
interfacing point with any external API. It's not _that_ much of a
hassle, as long as you are clear on what you use internally.

JM2C,
Alen

Re: [Algorithms] Left-handed vs. right-handed

[Graham H. <gra...@ge...>]

In the best of all possible worlds you would flip a coin and set a
universal convention for your whole project.  Just check the appropriate
box in your authoring application, create your graphics device with a
suitable flag and---oh, wait...

 

Since it's clearly "correct" to be agnostic, I prefer to work with the
chirality that the graphics driver expects.  You may have to apply a
transform with negative determinant to your data somewhere---but I would
rather do that once and for all time in a pre-process.  If you try to
cope in your code you will inevitably end up stuck between artists
(or---worse---mathematicians) who fervently believe the world is
right-handed and a driver which stubbornly assumes it's left-handed.  I
can guarantee that keeping track of where all the minus signs have to go
will hurt your head (been there!).

 

The view matrix is only one of your worries---there are several other
operations which are inherently 3D and come with a sign convention built
in.  The cross-product springs immediately to mind, but the really
filthy one is sampling a cube map---there are six faces, each with an
orientation, so if you have two different coordinate systems floating
around the sheer combinatorial possibilities for screwing this up are
pretty daunting...

 

Graham

 

 

 

From: Eric Haines [mailto:eri...@gm...] 
Sent: 06 May 2009 05:10
To: Game Development Algorithms
Subject: [Algorithms] Left-handed vs. right-handed

 

I've written up my way of thinking about left-handed and right-handed
world and viewing systems. It's a bit long-winded, but here it is:
http://www.realtimerendering.com/blog/left-handed-vs-right-handed-viewin
g/

 

This topic is in one sense basic stuff, but it leads to so much
confusion. Neither DirectX nor OpenGL does a good job of dealing with
this confusion, IMO. In our book we kind of sidestep the whole issue
(choose RH, stay RH). I'd love to get any feedback and corrections from
people on this list (either here on the list, via private email, or on
the blog), as I expect there are ways of thinking about it I hadn't even
considered or have misinterpreted.

 

Eric

Re: [Algorithms] Left-handed vs. right-handed

[Ruben P. <rub...@gm...>]

In my honest opinion, this is the same with "column major vs row major".
Whatever you choose just stick with it. Make a clear documentation about
your choose and how are you going to convert the data to your system. Then,
forget about it and never ever change the decision you made. :)

On Wed, May 6, 2009 at 6:09 AM, Eric Haines <eri...@gm...> wrote:

> I've written up my way of thinking about left-handed and right-handed world
> and viewing systems. It's a bit long-winded, but here it is:
> http://www.realtimerendering.com/blog/left-handed-vs-right-handed-viewing/
> This topic is in one sense basic stuff, but it leads to so much confusion.
> Neither DirectX nor OpenGL does a good job of dealing with this confusion,
> IMO. In our book we kind of sidestep the whole issue (choose RH, stay RH).
> I'd love to get any feedback and corrections from people on this list
> (either here on the list, via private email, or on the blog), as I expect
> there are ways of thinking about it I hadn't even considered or have
> misinterpreted.
>
> Eric
>
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
> i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>

[Algorithms] Left-handed vs. right-handed

[Eric H. <eri...@gm...>]

I've written up my way of thinking about left-handed and right-handed world
and viewing systems. It's a bit long-winded, but here it is:
http://www.realtimerendering.com/blog/left-handed-vs-right-handed-viewing/
This topic is in one sense basic stuff, but it leads to so much confusion.
Neither DirectX nor OpenGL does a good job of dealing with this confusion,
IMO. In our book we kind of sidestep the whole issue (choose RH, stay RH).
I'd love to get any feedback and corrections from people on this list
(either here on the list, via private email, or on the blog), as I expect
there are ways of thinking about it I hadn't even considered or have
misinterpreted.

Eric

Re: [Algorithms] Simple algorithm for regular polygon union

[Gregory J. <gj...@da...>]

Hi Jose,

You don't mention any of the ones you have found and rejected, so forgive me
if you've looked at GTS already:

http://gts.sourceforge.net/

It's LGPL, which is consistent with commercial usage (assuming you don't
mean "commercial on a console").

Greg

-----Original Message-----
From: Jose Marin [mailto:jos...@ya...] 
Sent: Tuesday, May 05, 2009 9:31 AM
To: gda...@li...
Subject: [Algorithms] Simple algorithm for regular polygon union


Hi,

I have found some libraries in the net to perform polygon operations, but I
need a very simple one: union of closed convex polygons.

Do you know any?

Thank you.

Jose


      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

----------------------------------------------------------------------------
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Simple algorithm for regular polygon union

[Graham R. ARA/S. <gr...@ar...>]

Note that if you union two convex polygons, the result is not necessarily convex. And, would result in two loops if the source polygons don't intersect each other or if one isn't contained in the other. You probably realize this, but I thought I'd point it out.

David Eberly's open source WildMagic engine has a sample application for performing Boolean set operations on polygons...not necessarily convex, but of course does handle those. Here is a link:

http://www.geometrictools.com/SampleFoundation/Polysolid2D/Polysolid2D.html

You can download a fairly minimal set of code (you don't need the entire engine...only a few files) and it does work as advertised. That is based on BSP trees, which a lot of people like but is not my personal preferred approach.

My own preferred approach to doing Polygon Booleans (and again, not restricted to convex), and the one I have used in my code, is based on a paper by Greiner and Hormann, "Efficient Clipping of Arbitrary Polygons," ACM Transactions on Graphics, Vol. 17, No. 2, April 1998, pp 71-83. This is a very straightforward paper.

I am sure there is something that is tuned for convex polygons, but I can't point you to anything that specific.

Graham

-----Original Message-----
From: Jose Marin [mailto:jos...@ya...] 
Sent: Tuesday, May 05, 2009 12:31 PM
To: gda...@li...
Subject: [Algorithms] Simple algorithm for regular polygon union


Hi,

I have found some libraries in the net to perform polygon operations, but I need a very simple one: union of closed convex polygons.

Do you know any?

Thank you.

Jose


      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list