[Bf-committers] Radiosity 'engine'
Tue, 10 Jun 2003 10:13:00 +0200
Hey man, nice to see you around here!
You smelly old F..z (apologies to other blendheads but somethings just have
to be said)
Please have a look at this cool code FSRad
http://www.fluidstudios.com/fsrad.html. Helaas not GPL but maybe usable as a
seperate executable with a little python wizardry etc.
> -----Original Message-----
> From: onk [mailto:firstname.lastname@example.org]
> Sent: 07 June 2003 16:13
> To: email@example.com
> Subject: [Bf-committers] Radiosity 'engine'
> hi there,
> first posting in this forum. Hoera!
> > Date: Sat, 7 Jun 2003 00:21:38 +0200 (CEST)
> > From: instinctive new media <firstname.lastname@example.org>
> > Hello!
> > I've been working with Radiosity quite a lot recently, and one
> > incredibly obvious question came to mind:
> > Why does the radiosity engine not SIMPLY use 'Add' textures instead
> > of crappifying the mesh and then using vertex colors?
> > You could continue to use your normal meshes, no complex
> > copying, replacing meshes, plus you could _ANIMATE_ (yes,
> that's right)
> > the radiosity light by simply animating the texture.
> > I don't get this! Why did it get coded this way? :)
> Hehe. History. Which I don't know of :-)
> Actually, you can do nice things with texture unwrapping and
> light situations almost realtime, depending on how realistic
> you want them.
> I agree, instead of subdivisions and vertcols, texture
> generation would
> make much more sense, save memory and time.
> It would also be interesting to enhance the radiosity engine
> to use the
> standard lighting (and not via 'emit' materials).
> There's just one little thing, that it would internally need
> a 'float'
> texture map to deal with arbitrary-intensity light 'quantums'.
> Are you going to touch that code ? or anyone else ?
> - Strubi
> Bf-committers mailing list