gdalgorithms-list Mailing List for Game Dev Algorithms (Page 28)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

> Does the input texture need to be square?

No, we pack rectangles into a rectangular texture.

+1 for this algorithm.  I've used it for quick and dirty lightmap packing
(for first pass - after rendering I use D3DX to create high quality texture
atlas).  You can make this algorithm run extremely fast since you can remove
all of the recursion and it just becomes:

class cLightmapPage
{
	std::list<Rect> m_FreeList;

public:
	cLightmapPage(const int w, const int h)
	{
		m_FreeList.push_back(Rect(0,0,w,h));
	}

	bool InsertRect(Rect *r)
	{
		for (std::list<Rect>::iterator rect_it=m_FreeList.begin();
rect_it!=m_FreeList.end(); ++rect_it)
		{
			if ((rect_it->w>=r->w) && (rect_it->h>=r->h))
			{
				while (1)
				{
					if ((rect_it->w==r->w) &&
(rect_it->h==r->h))
					{
						break;
					}

					int dw=rect_it->w-r->w,
						dh=rect_it->h-r->h;

					if (dw>dh)
					{

m_FreeList.push_back(Rect(rect_it->x+r->w,rect_it->y,dw,rect_it->h));
						rect_it->w=r->w;
					} else
					{

m_FreeList.push_back(Rect(rect_it->x,rect_it->y+r->h,rect_it->w,dh));
						rect_it->h=r->h;
					}
				}

				r->x=rect_it->x;
				r->y=rect_it->y;
				m_FreeList.erase(rect_it);
				return true;
			}
		}
		return false;
	}

	unsigned int GetFreePixels() const
	{
		unsigned int ret=0;
		for (std::list<Rect>::const_iterator
rect_it=m_FreeList.begin(); rect_it!=m_FreeList.end(); ++rect_it)
		{
			ret+=(rect_it->w*rect_it->h);
		}
		return ret;
	}
};

The while(1) loop runs at most 3 times iirc.  This is obviously not the
fastest implementation because you could probably make the outer search
quicker by sorting the rectangles somehow (or maybe by bucketing).

-----Original Message-----
From: David Bennett [mailto:dbe...@na...] 
Sent: Friday, August 14, 2009 7:51 PM
To: 'Game Development Algorithms'
Subject: Re: [Algorithms] Allocation of 2D space

One aspect of this algorithm that I'm curious about is:

Does the input texture need to be square?

If it turns out that you can pack all the rectangles into a k*(k/2) sized
texture rather than a k*k texture (where k is a power-of-2) that would be a
significant savings.

Thanks,

David Bennett
NAMCO BANDAI Games America Inc.

-----Original Message-----
From: Brian Meidell [mailto:br...@ga...]
Sent: Friday, August 14, 2009 11:21 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] Allocation of 2D space

I ended up using this algorithm, and I'm quite happy with it.

Thanks again for the suggestions!

/Brian

On 2009-08-13, at 23.24, Jim Scott wrote:

> I can also vouch for this guy.  :)  Since using it for lightmaps there
> I've also used it for more general texture atlases and for runtime
> font
> glyph packing in Guild Wars.  It's definitely fast enough for runtime
> use.
>
> -----Original Message-----
> From: Ivan-Assen Ivanov [mailto:iva...@gm...]
> Sent: Tuesday, August 11, 2009 3:01 PM
> To: Game Development Algorithms
> Subject: Re: [Algorithms] Allocation of 2D space
>
>> Try this: http://www.blackpawn.com/texts/lightmaps/default.html
>
> +1
>
> We use this to build a UI cache texture at runtime; packs reasonably
> well and is very fast.
>
>
----------------------------------------------------------------------------
--
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
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

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus
on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
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

I've been using it like that, and it works just fine.

On 2009-08-14, at 20.51, David Bennett wrote:

> One aspect of this algorithm that I'm curious about is:
>
> Does the input texture need to be square?
>
> If it turns out that you can pack all the rectangles into a k*(k/2)  
> sized texture rather than a k*k texture (where k is a power-of-2)  
> that would be a significant savings.
>
> Thanks,
>
> David Bennett
> NAMCO BANDAI Games America Inc.
>
> -----Original Message-----
> From: Brian Meidell [mailto:br...@ga...]
> Sent: Friday, August 14, 2009 11:21 AM
> To: Game Development Algorithms
> Subject: Re: [Algorithms] Allocation of 2D space
>
>
> I ended up using this algorithm, and I'm quite happy with it.
>
> Thanks again for the suggestions!
>
> /Brian
>
> On 2009-08-13, at 23.24, Jim Scott wrote:
>
>> I can also vouch for this guy.  :)  Since using it for lightmaps  
>> there
>> I've also used it for more general texture atlases and for runtime
>> font
>> glyph packing in Guild Wars.  It's definitely fast enough for runtime
>> use.
>>
>> -----Original Message-----
>> From: Ivan-Assen Ivanov [mailto:iva...@gm...]
>> Sent: Tuesday, August 11, 2009 3:01 PM
>> To: Game Development Algorithms
>> Subject: Re: [Algorithms] Allocation of 2D space
>>
>>> Try this: http://www.blackpawn.com/texts/lightmaps/default.html
>>
>> +1
>>
>> We use this to build a UI cache texture at runtime; packs reasonably
>> well and is very fast.
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and
>> focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> 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
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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

One aspect of this algorithm that I'm curious about is:

Does the input texture need to be square?

If it turns out that you can pack all the rectangles into a k*(k/2) sized texture rather than a k*k texture (where k is a power-of-2) that would be a significant savings.

Thanks,

David Bennett
NAMCO BANDAI Games America Inc.

-----Original Message-----
From: Brian Meidell [mailto:br...@ga...]
Sent: Friday, August 14, 2009 11:21 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] Allocation of 2D space

I ended up using this algorithm, and I'm quite happy with it.

Thanks again for the suggestions!

/Brian

On 2009-08-13, at 23.24, Jim Scott wrote:

> I can also vouch for this guy.  :)  Since using it for lightmaps there
> I've also used it for more general texture atlases and for runtime
> font
> glyph packing in Guild Wars.  It's definitely fast enough for runtime
> use.
>
> -----Original Message-----
> From: Ivan-Assen Ivanov [mailto:iva...@gm...]
> Sent: Tuesday, August 11, 2009 3:01 PM
> To: Game Development Algorithms
> Subject: Re: [Algorithms] Allocation of 2D space
>
>> Try this: http://www.blackpawn.com/texts/lightmaps/default.html
>
> +1
>
> We use this to build a UI cache texture at runtime; packs reasonably
> well and is very fast.
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
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

I ended up using this algorithm, and I'm quite happy with it.

Thanks again for the suggestions!

/Brian

On 2009-08-13, at 23.24, Jim Scott wrote:

> I can also vouch for this guy.  :)  Since using it for lightmaps there
> I've also used it for more general texture atlases and for runtime  
> font
> glyph packing in Guild Wars.  It's definitely fast enough for runtime
> use.
>
> -----Original Message-----
> From: Ivan-Assen Ivanov [mailto:iva...@gm...]
> Sent: Tuesday, August 11, 2009 3:01 PM
> To: Game Development Algorithms
> Subject: Re: [Algorithms] Allocation of 2D space
>
>> Try this: http://www.blackpawn.com/texts/lightmaps/default.html
>
> +1
>
> We use this to build a UI cache texture at runtime; packs reasonably
> well and is very fast.
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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

I'm looking at a related problem I've been banging my head against for  
a while, so seeing this, I figured I'd see if anyone here has some  
pointers.

I need a function to partition out a bunch of rects inside a fixed- 
size texture.It's basically for doing some deferred particle effects /  
billboards.

Now the thing is: The source areas can be too large to fit inside my  
fixed-size buffer. I'd like to have an upper bound on the total size  
usage - so if we have a lot of particle effects, I'd like them to  
share the preallocated buffer - so we lose some res in the offscreen  
stuff making the final rendering more blurry. Ideally, I'd like to  
have a notion of importance so I can lose more texture resolution for  
e.g. a faraway cloud, while only losing a bit for a nearby explosion.

This need to be evaluated on a per-frame basis as well, just to make  
the problem a bit more annoying. However, there won't be hundreds of  
these going on at the same time.

Any ideas?

Nicholas

On 13/08/2009, at 23.24, Jim Scott wrote:

> I can also vouch for this guy.  :)  Since using it for lightmaps there
> I've also used it for more general texture atlases and for runtime  
> font
> glyph packing in Guild Wars.  It's definitely fast enough for runtime
> use.
>
> -----Original Message-----
> From: Ivan-Assen Ivanov [mailto:iva...@gm...]
> Sent: Tuesday, August 11, 2009 3:01 PM
> To: Game Development Algorithms
> Subject: Re: [Algorithms] Allocation of 2D space
>
>> Try this: http://www.blackpawn.com/texts/lightmaps/default.html
>
> +1
>
> We use this to build a UI cache texture at runtime; packs reasonably
> well and is very fast.
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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

I can also vouch for this guy.  :)  Since using it for lightmaps there
I've also used it for more general texture atlases and for runtime font
glyph packing in Guild Wars.  It's definitely fast enough for runtime
use.

-----Original Message-----
From: Ivan-Assen Ivanov [mailto:iva...@gm...] 
Sent: Tuesday, August 11, 2009 3:01 PM
To: Game Development Algorithms
Subject: Re: [Algorithms] Allocation of 2D space

> Try this: http://www.blackpawn.com/texts/lightmaps/default.html

+1

We use this to build a UI cache texture at runtime; packs reasonably
well and is very fast.

That's very similar to how I pack font glyphs offline.  Although I don't 
rotate low, wide glyphs to the vertical.

Sort by height and then width and then place in rows across the 
texture.  One thing I do which doesn't make it very suitable for real 
time applications is to scan from the top left of the texture each time 
searching for a space to fit the next glyph.  That way I am usually able 
to fit smaller glyphs in the gaps left between the larger ones and down 
the right side of the texture.

And in my experience it actually turns out to be a reasonably optimal 
algorithm for similarly-sized, not-too-large rectangles.

Sebastian Sylvan wrote:
>
>
> On Tue, Aug 11, 2009 at 8:41 PM, Brian Meidell <br...@ga... 
> <mailto:br...@ga...>> wrote:
>
>     Hi,
>
>     I'm looking for an algorithm to allocate 2d rectangles of different
>     sizes from a larger 2d rectangle (small areas out of a large texture),
>     while wasting as little space as possible without being insanely slow.
>
>     Search terms that yield google results are welcome answers (I tried,
>     but I guess my google-fu proved too weak).
>
>
> "Rectangle packing" is probably a good search phrase.
>
> One simple, quick and reasonably good algorithm (that I can't find the 
> paper for right now), is to first align all the rectangles so their 
> longest axis is pointing along y, then sort them by this height. Then 
> you simply start putting down rectangles left to right until you reach 
> the right edge (you have to guess how wide this is - if you're trying 
> to optimize for "squareness" a binary search can help), and then you 
> go right-to-left underneath that until you're back at the first edge. 
> Then move this last row of rectangles up so that it's as close to the 
> first row as possible. Repeat until you've run out of rectangles.
>
> Hardly optimal, but at least it's simple!
>
>  
>
>      
>
> -- 
> Sebastian Sylvan
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

Thanks to everyone for the answers, I'll read up on the suggestions and 
make a choice.

Regards,
Brian Meidell

Jon Watte wrote:
> Bra...@pl... wrote:
>   
>> Try this: http://www.blackpawn.com/texts/lightmaps/default.html
>>   
>>     
>
>
> I implemented pretty much the same thing for real-time packing of 
> dynamic light maps for an XNA/Xbox program, and it did work very well. 
> Leakage/loss was generally less than for a typical power-of-two 
> quad-tree based allocator.
>
> Sincerely,
>
> jw
>
>
>
>   

Bra...@pl... wrote:
> Try this: http://www.blackpawn.com/texts/lightmaps/default.html
>   

I implemented pretty much the same thing for real-time packing of 
dynamic light maps for an XNA/Xbox program, and it did work very well. 
Leakage/loss was generally less than for a typical power-of-two 
quad-tree based allocator.

Sincerely,

jw

-- 

  Revenge is the most pointless and damaging of human desires.

> Try this: http://www.blackpawn.com/texts/lightmaps/default.html

+1

We use this to build a UI cache texture at runtime; packs reasonably
well and is very fast.

Brian Meidell <br...@ga...> wrote on 08/11/2009 12:41:42 PM:

> Hi,
> 
> I'm looking for an algorithm to allocate 2d rectangles of different 
> sizes from a larger 2d rectangle (small areas out of a large texture), 
> while wasting as little space as possible without being insanely slow.
> 

Try this: http://www.blackpawn.com/texts/lightmaps/default.html

Brad...

On Tue, Aug 11, 2009 at 8:41 PM, Brian Meidell <br...@ga...>wrote:

> Hi,
>
> I'm looking for an algorithm to allocate 2d rectangles of different
> sizes from a larger 2d rectangle (small areas out of a large texture),
> while wasting as little space as possible without being insanely slow.
>
> Search terms that yield google results are welcome answers (I tried,
> but I guess my google-fu proved too weak).

"Rectangle packing" is probably a good search phrase.

One simple, quick and reasonably good algorithm (that I can't find the paper
for right now), is to first align all the rectangles so their longest axis
is pointing along y, then sort them by this height. Then you simply start
putting down rectangles left to right until you reach the right edge (you
have to guess how wide this is - if you're trying to optimize for
"squareness" a binary search can help), and then you go right-to-left
underneath that until you're back at the first edge. Then move this last row
of rectangles up so that it's as close to the first row as possible. Repeat
until you've run out of rectangles.

Hardly optimal, but at least it's simple!

>

-- 
Sebastian Sylvan

Mike Shaver wrote:
> On Tue, Aug 11, 2009 at 3:41 PM, Brian Meidell<br...@ga...> wrote:
>> I'm looking for an algorithm to allocate 2d rectangles of different
>> sizes from a larger 2d rectangle (small areas out of a large texture),
>> while wasting as little space as possible without being insanely slow.
> 
> Sounds like you want a texture atlas, so something like
> http://www.gamasutra.com/view/feature/2530/practical_texture_atlases.php
> might be a good start?

If you're looking for a run-time rather than ahead-of-time algorithm, 
there's some Java code you could use as a start at 
http://kenai.com/projects/jogl/ in the JOGL SCM, under 
src/jogl/classes/com/sun/opengl/util/packrect/ . It divides the larger 
2d rectangle into variable-size "levels" and allocates out of those 
levels, performing compaction as necessary. It's far from optimal but 
has been pretty well tested.

-Ken

Hi,

Think Tetris.

Find a spot in the texture which minimizes waste (unused holes) and the
horizon line.

Best,
Jon Olick

On Tue, Aug 11, 2009 at 2:41 PM, Brian Meidell <br...@ga...>wrote:

> Hi,
>
> I'm looking for an algorithm to allocate 2d rectangles of different
> sizes from a larger 2d rectangle (small areas out of a large texture),
> while wasting as little space as possible without being insanely slow.
>
> Search terms that yield google results are welcome answers (I tried,
> but I guess my google-fu proved too weak).
>
> Regards,
> Brian Meidell
> The Game Equation
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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
>

On Tue, Aug 11, 2009 at 3:41 PM, Brian Meidell<br...@ga...> wrote:
> I'm looking for an algorithm to allocate 2d rectangles of different
> sizes from a larger 2d rectangle (small areas out of a large texture),
> while wasting as little space as possible without being insanely slow.

Sounds like you want a texture atlas, so something like
http://www.gamasutra.com/view/feature/2530/practical_texture_atlases.php
might be a good start?

Mike

Hi,

I'm looking for an algorithm to allocate 2d rectangles of different  
sizes from a larger 2d rectangle (small areas out of a large texture),  
while wasting as little space as possible without being insanely slow.

Search terms that yield google results are welcome answers (I tried,  
but I guess my google-fu proved too weak).

Regards,
Brian Meidell
The Game Equation

Mark Sararu schrieb:
> Ivan-Assen Ivanov wrote:
>> There's this weird piece of hardware that has
>> sold in the mid-two-digit millions, yet refuses to sample from its framebuffer,
>> so if you're doing two passes, you have to do transfer the results from the
>> first pass into RAM, and 5x5 and 9x9 Gaussian kernels turn out faster
>> in one pass instead of separated in H and V.
>>
>>   
> I'm curious, what hardware is that? This is the first I've heard of this 
> and I'm wondering if it's something I'd need to worry about.

It's not something you need to worry about unless you're a console 
developer.

Cheers,
-Fabian

heh ... I never thought of trying that ... I just removed the fullscreen
blur in the end ... it didn't add anything to the game and was just there
because another platform, with a very very quick frame buffer that sold even
more units, had cycles to burn :D

2009/8/11 Ivan-Assen Ivanov <iva...@gm...>

> > Second, you can calculate the Gaussian blur in a single post-processing
> > pass if you want. It's no different from doing the horizontal and
> > vertical in two different passes, except for the amount of math
> > involved. If you do that, then you'll be using a large amount of pixel
> > shader instructions compared to framebuffer writes, which will generally
> > be slower than just doing two separate passes on render targets. All
> > hardware is decent enough at fill rate compared to shader instructions
> > that it doesn't make sense to try to do it in a single post-process
> > pass. When we get a 1000:1 ratio of shader ops:framebuffer writes, that
> > detemrination may change, but we're nowhere near there just yet :-)
>
> I beg to disagree - it still depends on the particular hardware and
> filter sizes.
>
> There's this weird piece of hardware that has
> sold in the mid-two-digit millions, yet refuses to sample from its
> framebuffer,
> so if you're doing two passes, you have to do transfer the results from the
> first pass into RAM, and 5x5 and 9x9 Gaussian kernels turn out faster
> in one pass instead of separated in H and V.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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
>

Ivan-Assen Ivanov wrote:
>> Second, you can calculate the Gaussian blur in a single post-processing
>> pass if you want. It's no different from doing the horizontal and
>> vertical in two different passes, except for the amount of math
>> involved. If you do that, then you'll be using a large amount of pixel
>> shader instructions compared to framebuffer writes, which will generally
>> be slower than just doing two separate passes on render targets. All
>> hardware is decent enough at fill rate compared to shader instructions
>> that it doesn't make sense to try to do it in a single post-process
>> pass. When we get a 1000:1 ratio of shader ops:framebuffer writes, that
>> detemrination may change, but we're nowhere near there just yet :-)
>>     
>
> I beg to disagree - it still depends on the particular hardware and
> filter sizes.
>
> There's this weird piece of hardware that has
> sold in the mid-two-digit millions, yet refuses to sample from its framebuffer,
> so if you're doing two passes, you have to do transfer the results from the
> first pass into RAM, and 5x5 and 9x9 Gaussian kernels turn out faster
> in one pass instead of separated in H and V.
>
>   
I'm curious, what hardware is that? This is the first I've heard of this 
and I'm wondering if it's something I'd need to worry about.

> Second, you can calculate the Gaussian blur in a single post-processing
> pass if you want. It's no different from doing the horizontal and
> vertical in two different passes, except for the amount of math
> involved. If you do that, then you'll be using a large amount of pixel
> shader instructions compared to framebuffer writes, which will generally
> be slower than just doing two separate passes on render targets. All
> hardware is decent enough at fill rate compared to shader instructions
> that it doesn't make sense to try to do it in a single post-process
> pass. When we get a 1000:1 ratio of shader ops:framebuffer writes, that
> detemrination may change, but we're nowhere near there just yet :-)

I beg to disagree - it still depends on the particular hardware and
filter sizes.

There's this weird piece of hardware that has
sold in the mid-two-digit millions, yet refuses to sample from its framebuffer,
so if you're doing two passes, you have to do transfer the results from the
first pass into RAM, and 5x5 and 9x9 Gaussian kernels turn out faster
in one pass instead of separated in H and V.

> Siggraph is becoming more like GDC every year. :-)

On that note, I wanted to mention that SIGGRAPH is making a big push to
get more game content in 2010 (disclosure: I'm on the conference
committee). SIGGRAPH may seem daunting, but a 20-minute SIGGRAPH Talk
(they used to be called Sketches) is actually less work than a 60-minute
GDC presentation. They love to get nice practical nuggets of stuff - tips
and tricks, etc. You don't need to invent spherical harmonics to get your
stuff accepted! Some good examples of game developer Talks from this year,
with their abstracts:

* Houdini in a Games Pipeline - Using Side Effects Houdini as part of the
art-production pipeline for Sony's PlayStation 3 game: Killzone 2.

* Spore API: Accessing a Unique Database of Player Creativity -
Applications built with the Spore API, which can access information about
the millions of creations uploaded from Spore.

* Fight Night 4: Physics-Driven Animation and Visuals - The game team CG
supervisor and lead game-play engineer explore the innovative
physics-driven game play and visual style of the new Fight Night 4 game
from Electronic Arts.

* Radially Symmetric Reflection Maps - A technique for rendering
hand-painted, radially symmetric area lights at real-time rates, using a
new representation based on prefiltered reflection maps (presented by
Double Fine, this was used in Brutal Legend).

So if you have any cool stuff you've done lately, you might want to
consider submitting it to SIGGRAPH. The CFP for Talks can be found here:
http://www.siggraph.org/s2010/for_submitters/talks. If you're feeling more
ambitious, you could submit a Course proposal
(http://www.siggraph.org/s2010/for_submitters/courses).

Thanks,

Naty Hoffman

On Mon, Aug 10, 2009 at 8:53 AM, Eric Haines<eri...@gm...> wrote:
>
> (I'm under the impression that some instructors were
> making slides up to the last minute).

Siggraph is becoming more like GDC every year. :-)

- Robin Green.

I think all course notes will eventually appear in the ACM digital
library. Some courses' notes are on the Full Conference DVD-ROM.

The complete notes for the Advances in Real-Time Rendering course
don't seem to be anywhere as of yet. I did notice that Anton
Kaplanyan's slides, PDF, and movies relating to his real-time GI talk
are available on Crytek's site:
http://www.crytek.com/technology/presentations/

Nick

2009/8/10 Eric Haines <eri...@gm...>:
> Natasha said during the course that the Advances in RTR course notes will be
> posted in a few weeks (I'm under the impression that some instructors were
> making slides up to the last minute).
> Eric
>
> On Mon, Aug 10, 2009 at 10:55 AM, Jon Greenberg <jon...@rc...>
> wrote:
>>
>> Hopefully this isn’t considered off topic, but would anyone know if the
>> course notes for Advances in Real-Time Rendering in 3D Graphics and Games
>> have been posted anywhere?  I noticed that the notes for the Beyond
>> Programmable Shading were all posted here: http://s09.idav.ucdavis.edu/, for
>> example.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Jon
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> 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
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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
>

Natasha said during the course that the Advances in RTR course notes will be
posted in a few weeks (I'm under the impression that some instructors were
making slides up to the last minute).
Eric

On Mon, Aug 10, 2009 at 10:55 AM, Jon Greenberg
<jon...@rc...>wrote:

>  Hopefully this isn’t considered off topic, but would anyone know if the
> course notes for Advances in Real-Time Rendering in 3D Graphics and Games
> have been posted anywhere?  I noticed that the notes for the Beyond
> Programmable Shading were all posted here: http://s09.idav.ucdavis.edu/,
> for example.
>
>
>
> Thanks,
>
>
>
> Jon
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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
>

2000	Jan	Feb	Mar	Apr	May	Jun	Jul (390)	Aug (767)	Sep (940)	Oct (964)	Nov (819)	Dec (762)
2001	Jan (680)	Feb (1075)	Mar (954)	Apr (595)	May (725)	Jun (868)	Jul (678)	Aug (785)	Sep (410)	Oct (395)	Nov (374)	Dec (419)
2002	Jan (699)	Feb (501)	Mar (311)	Apr (334)	May (501)	Jun (507)	Jul (441)	Aug (395)	Sep (540)	Oct (416)	Nov (369)	Dec (373)
2003	Jan (514)	Feb (488)	Mar (396)	Apr (624)	May (590)	Jun (562)	Jul (546)	Aug (463)	Sep (389)	Oct (399)	Nov (333)	Dec (449)
2004	Jan (317)	Feb (395)	Mar (136)	Apr (338)	May (488)	Jun (306)	Jul (266)	Aug (424)	Sep (502)	Oct (170)	Nov (170)	Dec (134)
2005	Jan (249)	Feb (109)	Mar (119)	Apr (282)	May (82)	Jun (113)	Jul (56)	Aug (160)	Sep (89)	Oct (98)	Nov (237)	Dec (297)
2006	Jan (151)	Feb (250)	Mar (222)	Apr (147)	May (266)	Jun (313)	Jul (367)	Aug (135)	Sep (108)	Oct (110)	Nov (220)	Dec (47)
2007	Jan (133)	Feb (144)	Mar (247)	Apr (191)	May (191)	Jun (171)	Jul (160)	Aug (51)	Sep (125)	Oct (115)	Nov (78)	Dec (67)
2008	Jan (165)	Feb (37)	Mar (130)	Apr (111)	May (91)	Jun (142)	Jul (54)	Aug (104)	Sep (89)	Oct (87)	Nov (44)	Dec (54)
2009	Jan (283)	Feb (113)	Mar (154)	Apr (395)	May (62)	Jun (48)	Jul (52)	Aug (54)	Sep (131)	Oct (29)	Nov (32)	Dec (37)
2010	Jan (34)	Feb (36)	Mar (40)	Apr (23)	May (38)	Jun (34)	Jul (36)	Aug (27)	Sep (9)	Oct (18)	Nov (25)	Dec
2011	Jan (1)	Feb (14)	Mar (1)	Apr (5)	May (1)	Jun	Jul	Aug (37)	Sep (6)	Oct (2)	Nov	Dec
2012	Jan	Feb (7)	Mar	Apr (4)	May	Jun (3)	Jul	Aug	Sep (1)	Oct	Nov	Dec (10)
2013	Jan	Feb (1)	Mar (7)	Apr (2)	May	Jun	Jul (9)	Aug	Sep	Oct	Nov	Dec
2014	Jan (14)	Feb	Mar (2)	Apr	May (10)	Jun	Jul	Aug	Sep	Oct	Nov (3)	Dec
2015	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (12)	Nov	Dec (1)
2016	Jan	Feb (1)	Mar (1)	Apr (1)	May	Jun (1)	Jul	Aug (1)	Sep	Oct	Nov	Dec
2017	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec
2022	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (2)	Dec