Re: [Aqsis-development] Rendering preloaded (and potentially large) geometry

[Paul G. <aq...@gm...>]

Procedurals are rendered at bucket rendering time. They only get
called when the bucket they are in is hit. One common example is
grass, the procedural is initially setup to cover a large area, and
will probably be hit in the first bucket. But then, rather than
directly creating the grass, which would, as you say, result in
effectively stream time procedurals, it creates more of its own
procedural type, but covering a smaller area. The memory use for the
procedural is relatively small, so many of these can be created quite
cheaply. Only actually creating geometry when it will be rendered
entirely as part of the current bucket.

Cheers

PaulG

On 6/15/05, Ray Gardener <ra...@da...> wrote:
> Hmm... yeah, that appears more elegant, but... looking at the interface
> spec it seems that the RiProcedural's subdivider just emits Ri*
> primitive calls to translate the custom primitive into a set of standard
> ones. The RIB stream hits a procedural, and then expands it into a
> regular RiAttribute block. The problem is that the bounds are for the
> object, so all the geometry must be provided and hence duped.
>=20
> Taking the detail arg into account helps, but then things become
> nontrivial -- the procedural has to run a mesh reduction algo which may
> produce popping if flyover animation occurs. Not insurmountable,
> however. It's going to be... a big, sophisticated procedural. :) I
> remember that opening sequence in "A Bug's Life" where the cam dollies
> towards the island, and thinking, they're probably doing something like
> that. If I whip one up I'll open source it; an RiProc like that should
> be a standard component for anyone doing Renderman landscaping. Or maybe
> someone else has one already?
>=20
> Is there any way to have geometry generated at bucket render time rather
> than stream parsing time?
>=20
> Rocks and veg I'm not worried about; instancing should work fine.
>=20
> Ray
>=20
>=20
>=20
> Paul Gregory wrote:
> > Yes, Aqsis does supoprt both external run program, and DSO procedurals.
> >
> > PaulG
> >
> > On 6/14/05, Dan Maas <dm...@dc...> wrote:
> >
> >>>That's a pity. I can't guarantee that there's enough RAM to hold anoth=
er
> >>>copy of the object.
> >>
> >>Traditionally the way this problem is solved is by using RiProcedurals
> >>(geometry generated at render time on demand), which can take the form
> >>of static RIB files on disk, an external executable program, or a
> >>DLL/DSO. I'm not sure if Aqsis supports these at the moment?
> >>
> >>(although your worry may be unnecessary - REYES renderers are quite
> >>efficient at handling huge amounts of geometry, as long as the
> >>highest-level primitives you pass in, i.e. the patch vertices, fit in
> >>RAM).
> >>
> >>Just a note on generating terrain in strips - you may get cracking on
> >>strip boundaries since neighboring patches can be diced at different
> >>rates. Some renderers fix this problem by stitching vertices together,
> >>which requires that you submit the entire terrain in a single RIB
> >>statement.
> >>
> >>Regards,
> >>Dan
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you s=
hotput
> >>a projector? How fast can you ride your desk chair down the office luge=
 track?
> >>If you want to score the big prize, get to know the little guy.
> >>Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20
> >>_______________________________________________
> >>Aqsis-development mailing list
> >>Aqs...@li...
> >>https://lists.sourceforge.net/lists/listinfo/aqsis-development
> >>
> >
> >
> >
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> Aqsis-development mailing list
> Aqs...@li...
> https://lists.sourceforge.net/lists/listinfo/aqsis-development
>=20


--=20
Paul Gregory
http://www.aqsis.org
ICQ: 156088409