Commit Graph

5 Commits

Author SHA1 Message Date
Brecht Van Lommel
460dd7a7bb Render Instancing
=================

Big commit, but little user visible changes.

- Dupliverts and duplifaces are now rendered as instances, instead
  of storing all of the geometry for each dupli, now an instance is
  created with a matrix transform refering to the source object.
  This should allow us to render tree leaves more memory efficient.

- Radiosity and to some degree raytracing of such objects is not
  really efficient still. For radiosity this is fundamentally hard
  to solve, but raytracing an octree could be created for each object,
  but the current octree code with it's fixed size doesn't allow this
  efficiently.

- The regression tests survived, but with I expect that some bugs will
  pop up .. hopefully not too many :).

Implementation Notes
====================

- Dupligroups and linked meshes are not rendered as instances yet,
  since they can in fact be different due to various reasons,
  instancing of these types of duplis that are the same can be added
  for them at a later point.

- Each ObjectRen now stores it's own database, instead of there being
  one big databases of faces, verts, .. . Which objects that are actually
  rendered are defined by the list of ObjectRenInstances, which all refer
  to an ObjectRen.

- Homogeneous coordinatess and clipping is now not stored in vertices
  anymore, but instead computed on the fly. This couldn't work for
  instances. That does mean some extra computation has to be done, but
  memory lookups can be slow too, and this saves some memory. Overall
  I didn't find a significant speed impact.

- OSA rendering for solid and ztransp now is different. Instead of e.g.
  going 8 times over the databases times and rendering the z-buffer, it
  now goes over the database once and renders each polygon 8 times. That
  was necessary to keep instances efficient, and can also give some
  performance improvement without instances.

- There was already instancing support in the yafray export code, now it
  uses Blender's render instances for export.

- UV and color layer storage in the render was a bit messy before, now
  should be easier to understand.

- convertblender.c was reorganized somewhat. Regular render, speedvector
  and baking now use a single function to create the database, previously
  there was code duplicated for it.

- Some of these changes were done with future multithreading of scene
  and shadow buffer creation in mind, though especially for scene creation
  much work remains to be done to make it threadsafe, since it also involves
  a lot of code from blenkernel, and there is an ugly conflict with the way
  dupli groups work here .. though in the render code itself it's almost there.
2007-12-15 20:41:45 +00:00
Kent Mein
4e2143f639 This commit fixes up a bunch of svn properties to hopefully make things a little nicer for everyone.
Patch provied by gsrb3d

bug tracker #7061

Kent
2007-08-28 10:07:08 +00:00
Alfredo de Greef
649dcd94bb Yafray 'should' now work again. A bit more testing needed.
But seems to work sofar anyway, composit nodes should work as well.
2006-05-29 03:59:12 +00:00
Alejandro Conty Estevez
ed86852f7e New export through plugin scheme for yafray. It is working on linux and mac os x
Needs latest yafray, you can get it from cvs, but I have also binaries
for os x here:

http://www.coala.uniovi.es/~jandro/noname/downloads/yafray-0.0.6-3.pkg.zip

To use it, go to yafray panels (global settings) and uncheck the "xml" button.
That would tell the export code to avoid xml export and use the yafray plugin
instead. You'll see the render being draw while running and you can even stop it
with ESC key.

Since I'm sure problems will appear, expect updates soon.
Remember: does not work on win32
2004-06-16 18:44:12 +00:00
Alejandro Conty Estevez
5c51bd7e56 Code reorganization to allow a clean export to plugin alternative for
yafray
2004-01-08 23:12:56 +00:00