gdalgorithms-list

RE: [Algorithms] vipm instancing

[Tom F. <to...@mu...>]

The only memory that needs to be replicated is index memory - that's what
we're talking about, right? The vertex memory can be shared between all
instances, since you never change the vertex data when collapsing/expanding
edges.

I did have a vague outline of a scheme to get better vertex cache coherency
(which normal VIPM lacks), and which, almost as a side-effect, allows you to
share much more index data between instances. Here's a quick brain-dump. One
day I'll write it up properly.

This could be improved by having several versions of the index buffer, but
pre-optimised for polygon number ranges:

For the range 100-200 triangles, I stripify the first 100 tris in the index
buffer, and then the rest are in collapse order. Over 200, I switch to the
200-400 range, which has the first 200 indices stripified, and the next 200
in collapse order. So this just involves switching index lists every power
of two triangles. Note that I haven't actually tried this yet!

You could also make the switches more often, i.e. every 100 tris. Also note
that some of the non-vanishing tris need to be modified during
expands/collapses, so they need to be in the un-optimised chunk as well.

I did write this all down properly somewhere - I've lost it now.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Paul Firth [mailto:pa...@ar...]
> Sent: 03 August 2000 11:30
> To: gda...@li...
> Subject: [Algorithms] vipm instancing
> 
> 
> Hi,
> 
> I was wondering if anyone can offer any advice about how to
> save memory when instancing multiple vipm models in a scene.
> 
> Ideally what I'd like to have is each instance only taking enough
> memory for as many tris as it currently has in its LoD, but I can't
> see any way to neatly increase this amount without some kind of
> crazy slow memory re-organisation.
> 
> I could use buckets but I really don't want to waste all that 
> luvly ram,
> does anyone have any ideas?
> 
> Cheers, Paul.
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

RE: [Algorithms] vipm instancing

[Tom F. <to...@mu...>]

That's pretty much the one I suggested, but you lose the whole
continuousness, which is rather the point of VIPM - if you wanted discrete
levels, just precompute them and use static LoD, which is even faster. I was
suggesting you have some precompiled "base" triangle counts (e.g. a 300 tri
one), and then just the extra few replicated for each instance to work up to
the desired precise tri count (i.e. another 23 to get to 323 tris, which is
what the error metric says you should have).

It's a little more complex than that (because existing tris get modified by
adding new tris, so those can't actually be in the precompiled chunk), but
that's the essence.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Thatcher Ulrich [mailto:tu...@tu...]
> Sent: 04 August 2000 15:04
> To: gda...@li...
> Subject: Re: [Algorithms] vipm instancing
> 
> 
> 
> On Fri, 4 Aug 2000, Paul Firth wrote:
> 
> > > You can do it by having a list of faces per object (faces 
> can't be shared).
> > > Each object will use the same vertex buffer and the same 
> vsplit list, but
> > > each object is in a different state, with different VB_Len and
> > > CurrentVsplit.
> > > This needs memory but if you have a 64k polys object you 
> only need 64K*2
> > > bytes per object, which isn't very much.
> > 
> > This is how I'm doing it currently, the trouble is that 
> every instance uses
> > the same amount of memory which is a huge waste if I have many
> > instances at a high distance.
> > 
> > Its annoying because if this idea worked and you could have 
> instances with
> > almost 0 memory waste you could have crazy numbers of polys in your
> > scene.
> 
> How about: have a table of (say) ten vipm instances, which 
> are then shared
> by all visible instances of that model.  You'd have some kind 
> of voting or
> averaging scheme for deciding what the poly count should be 
> for each of
> the ten actual vipm instances.  This would hurt the 
> continousness of the
> LOD scheme when more than 10 instances are visible, but then you could
> make whole giant forests of vipm'd trees without killing memory.
> 
> -Thatcher
> tulrich.com
> 
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

[Algorithms] re: vipm instancing

[Paul F. <pa...@ar...>]

> >I thought of maybe using some kind of linked triangle list with the extra
> >tris being paged in, stuck in a different chunk of ram then linked to the
> >last chunk. Bad fragmentation and cache trouble I fear, though...
>
> Why do you say that?  You could have a chunk of ram, say 2 MB, which you
> reserve for all your VIPM index lists.  Then you could write your own,
> simple memory manager for the VIPM index lists.  You actually wouldn't need
> linked lists, you could implement a "pushing" manager where you moved other
> lists around to make room for you to just grow your list linearly.

Wouldn't that be slow? If you have a mesh currently containing 50,000 tris
and you need to up it but havent the ram in the current location, you'd need
to move 50,000*3*2 (~300k) bytes of ram to some other location. Surely that
would ruin the cache etc?

How much allowance would you make in terms of padding each time you
allocated a new chunk of ram for the higher lod mesh?

Cheers, Paul.

Re: [Algorithms] finding an optimal OBB

[Charles B. <cb...@cb...>]

Ok, so far as I can tell, all he's doing there is a brute
force minimization of the volume by searching the 2d orientation
space of the box.  I suppose that's probably as good as anything
else.  You could probably get a good solution by starting along
the axis of linear-best-fit and just finding a local minimum of
the volume.

I wish the Magic code was better commented, it would make it
10x more useful, but beggars can't be choosers, I suppose...

>Your savior and mine, magic source code.
>http://www.magic-software.com/MgcContainment.html
>Thank you, Dave E. My Dave E. book is on its way, and am looking forward to
>it.
>
>The math here (Ron L. would have to correct me if I were wrong about this)
>is better / more correct than most on-line tutorials, papers and algorithms.
>
>Corrinne Yu
>
--------------------------------------
Charles Bloom           www.cbloom.com

[Algorithms] Return of the front clip plane

[Jason Z. <zi...@n-...>]

Hi everyone, if you all remember our last episode "Attack of the Front Clip
Plane", we all learned that the further it is out the better zbuffer
accuracy you have.  Much was learned by most.  :)

Pushing my front clip out to 1 unit solved all of my zbuffer artifacts
nicely in the last game.  We are trying some new things for the new game and
running into a problem that was mostly glossed over in the prequel to this
email: collision and clipping of close-by objects.  Our game is first
person, and when you get within 1 unit of an object it will get clipped out.
This is obviously pretty nasty.  :)  I remember one solution to this
suggested was to dynamically move the front clip each frame depending on how
close objects are.

Another solution is to just make your player's bounding volume larger so you
can't get close enough to stuff to clip into it, this works okay but I find
that you have to keep the player from getting closer than 3 units with a 1
unit clip because of viewport rotation (just keeping the player 1 unit away
is fine if you are staring straight at a wall but as soon as you rotate the
edges of your viewport will clip it).

Anyone else have any other ideas?  Right now it looks like I might be going
the dynamic front clip route but I really don't want to, I have a feeling we
will be seeing lots of artifacts out in the wilderness because the player
will always be walking by a tree that they might not even be looking at.

For reference we use feet as units, with a front clip of 1 foot and a back
clip of 1000 feet.

Thanks,

- Jason Zisk
- nFusion Interactive LLC

Re: [Algorithms] Return of the front clip plane

[Jamie F. <j.f...@re...>]

We're looking at that now.

Current plan:

Clip important scenery.
Cull unimportant objects / scenery when they get tricky.
Clamp important objects to viewport.

But we'll fiddle it for quality later. Our primary goal is to maintain the
illusion of solidity of objects, so that if the camera gets close to something /
in it, you don't start losing polys and seeing things you shouldn't. Having
decent enough collision code to (usually) keep your camera out of objects is a
good thing :)

We've plenty of Z buffer, and know we will always have, so we don't have to be
too careful there.

Anyone have any better ideas?

Jamie


Jason Zisk wrote:

> Hi everyone, if you all remember our last episode "Attack of the Front Clip
> Plane", we all learned that the further it is out the better zbuffer
> accuracy you have.  Much was learned by most.  :)
>
> Pushing my front clip out to 1 unit solved all of my zbuffer artifacts
> nicely in the last game.  We are trying some new things for the new game and
> running into a problem that was mostly glossed over in the prequel to this
> email: collision and clipping of close-by objects.  Our game is first
> person, and when you get within 1 unit of an object it will get clipped out.
> This is obviously pretty nasty.  :)  I remember one solution to this
> suggested was to dynamically move the front clip each frame depending on how
> close objects are.
>
> Another solution is to just make your player's bounding volume larger so you
> can't get close enough to stuff to clip into it, this works okay but I find
> that you have to keep the player from getting closer than 3 units with a 1
> unit clip because of viewport rotation (just keeping the player 1 unit away
> is fine if you are staring straight at a wall but as soon as you rotate the
> edges of your viewport will clip it).
>
> Anyone else have any other ideas?  Right now it looks like I might be going
> the dynamic front clip route but I really don't want to, I have a feeling we
> will be seeing lots of artifacts out in the wilderness because the player
> will always be walking by a tree that they might not even be looking at.
>
> For reference we use feet as units, with a front clip of 1 foot and a back
> clip of 1000 feet.
>
> Thanks,
>
> - Jason Zisk
> - nFusion Interactive LLC
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] Return of the front clip plane

[Gil G. <gg...@ma...>]

> For reference we use feet as units, with a front clip of 1 foot and a back
> clip of 1000 feet.

I think we use a near clip plane of about 8 inches and the bbox we use to
keep the player from clipping into walls is entirely reasonable. In my
opinion, even if you could have a near clip plane of 0, you wouldn't really
want it anyway. Putting something right into the players face is
disorienting.
-Gil

----- Original Message -----
From: "Jason Zisk" <zi...@n-...>
To: <gda...@li...>
Sent: Thursday, August 03, 2000 10:46 AM
Subject: [Algorithms] Return of the front clip plane


> Hi everyone, if you all remember our last episode "Attack of the Front
Clip
> Plane", we all learned that the further it is out the better zbuffer
> accuracy you have.  Much was learned by most.  :)
>
> Pushing my front clip out to 1 unit solved all of my zbuffer artifacts
> nicely in the last game.  We are trying some new things for the new game
and
> running into a problem that was mostly glossed over in the prequel to this
> email: collision and clipping of close-by objects.  Our game is first
> person, and when you get within 1 unit of an object it will get clipped
out.
> This is obviously pretty nasty.  :)  I remember one solution to this
> suggested was to dynamically move the front clip each frame depending on
how
> close objects are.
>
> Another solution is to just make your player's bounding volume larger so
you
> can't get close enough to stuff to clip into it, this works okay but I
find
> that you have to keep the player from getting closer than 3 units with a 1
> unit clip because of viewport rotation (just keeping the player 1 unit
away
> is fine if you are staring straight at a wall but as soon as you rotate
the
> edges of your viewport will clip it).
>
> Anyone else have any other ideas?  Right now it looks like I might be
going
> the dynamic front clip route but I really don't want to, I have a feeling
we
> will be seeing lots of artifacts out in the wilderness because the player
> will always be walking by a tree that they might not even be looking at.
>
> For reference we use feet as units, with a front clip of 1 foot and a back
> clip of 1000 feet.
>
> Thanks,
>
> - Jason Zisk
> - nFusion Interactive LLC
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list