Yamyam: 1版をインポートしました

2018-06-28T17:47:26Z

1版をインポートしました

wiki>Mindrones bot: Robot: Automated text replacement (-[[doc: +[[Doc:)

2010-05-27T15:09:29Z

Robot: Automated text replacement (-[[doc: +[[Doc:)

新規ページ

=Introduction=
During project Orange, pretty much all of the old rendercode was rewritten from scratch, resulting in a much better/more coherent framework. However, this also meant that the YafRay integration code (that was pretty much "hacked" on top of Blender) had to go.

Now it seems like a good API for external renderers is in place, especially since people have been experimenting with a whole bunch of external renderers (after YafRay was wrongfully declared dead by some). Here's a list of some renderers that got a lot of attention lately:
* [http://www.povray.org POVRay] - Good old POV-Ray got a lot of attention because Ramon Carlos Ruiz (RCRuiz) integrated POV-Ray into 2.41, using the YafRay integration code as a base for his work. [http://elysiun.com/forum/viewtopic.php?t=58027 elYsiun thread] but, of course, the old [http://jmsoler.free.fr/util/blenderfile/fr/povanim.htm Povanim script exporter] worked also since five long years with Megapov 0.7, Megapov1.0 and POV-Sub too. [http://blenderartists.org/forum/showthread?t=13318 elYsiun thread].
* [http://yafray.org YafRay] - Contrary to popular believe, YafRay is not dead. Actually, 0.0.8-2 (these guys need to get better versioning :o)) is a very good renderer. Lynx3D started working on his own renderer, which might or might not become the new YafRay. Still a very popular renderer mostly because of it's integration with Blender in the past. [http://forum.yafray.org forum]
* [http://aqsis.org Aqsis] - RenderMan compliant renderer. ShortWave is working on a python script that uses a custom GUI library to be able to export from Blender. [http://wiki.aqsis.org/doku.php?id=dev:blender_plugin BtoR project page]
* [http://homepages.paradise.net.nz/nickamy/indigo.html Indigo] - Pretty new, unbiased renderer by Nicholas Chapman (windows only atm). Ewout and several others have been working on a simple python [[Doc:Tutorials/Render/Export/Indigo|export script]]. [http://www.flipcode.dxbug.com/board.php?forum=9 forum]
* [http://sunflow.sourceforge.net/ Sunflow] - Java based GI rendering system. Has quite a good python [http://sunflow.sourceforge.net/sunflow_export.py exporter] (with many options, that is). [http://elysiun.com/forum/viewtopic.php?t=59555 elYsiun thread]
* [http://www.softlab.ntua.gr/~jpanta/Graphics/Kerkythea/ Kerkythea] Standalone renderer, very fast GI. Available for Linux & Windows. [http://cobalt3d.free.fr/images_3dblender/kerkythea/documentation/Blender2Kerkythea_en.htm#scriptpython_for_linux_users script exporter], [http://cobalt3d.free.fr/images_3dblender/kerkythea/documentation/Blender2Kerkythea_en.htm Blender2KT exporter] [http://www.kerkythea.net/phpBB2/index.php forum], [http://blenderartists.org/forum/showthread.php?t=74247&highlight=kerkythea elYsiun thread]

=Render API wishlist=
All of these renderers have to export their meshes, rendersettings & materials one way or another. Currently the only way to do this is via a python script. This is not at all optimal - the Draw function (GUI programming) is very buggy, and still the integration is a bit primitive. What is needed is a good level of abstraction that can be utilised by an external plugin. It also seems that mesh exporting is the smallest problem to overcome (even though there's a lot of room for improvement here! Try exporting a mesh that's subdivided at renderlevel WITH all other things like bone deformation, modifiers etc. applied!). The biggest challenge here is the material system, and being able to give meaning to some renderer specific features inside blender (DOF, special lamp types etc.).

I've tried to make a list of what I think is needed for a good render API:
* Proper level of abstraction - communication between renderer (or render-exporter) and Blender should be straightforward (unlike the way textureplugins are currently implemented, for example)
* C-API - In a lot of cases, a python script is not very convenient. Integration on the level YafRay used to be is what we should aim for (if not better), but this is difficult at best. If YafRay was updated in the past, Blender could not be adjusted to that untill the next Blender release. This makes third parties too much dependent on Blender itself. If it was a plugin, you could just update the dll and continue happily. Updating (and maintaining!) becomes much easier this way.
* Custom properties - to be able to save render & material settings (and more), it's very important to have a good definition of some kind of 3rd party storage place. Attaching renderer specific properties to any element inside Blender should be possible.
* Enabling/disabling GUI panels - In some cases (especially Aqsis), Blender's material system has no meaning at all for an external renderer. This should be reflected in the UI by some kind of change. It would be ideal if the renderer could 'create' new panels in the UI, with it's own settings, but also disabling non-relevant panels AND options. For example, there's no point in having a 'threads' button if this function is not available for that renderer. This goes to a certain level of course, you can't expect Blender to fully adapt to the abilities of an external renderer, but ''at least'' panel creation/hiding should be supported. This doesn't mean all these settings are lost btw, they are just switched off (or on) when the user switches renderer. This means an object could contain a material in Blender Internal that's completely different from a material in Aqsis for example!
* Support for custom lamp types (and perhaps other custom objects/primitives too!) - Not every renderer supports every lamp type Blender has, but sometimes a renderer even has more lamp types. The plugin should be able to add something like this to the UI (and the scenedata of course), and give it some meaning. DOF representation was already mentioned, but there are many other types of things. This is an extendability problem that perhaps surpasses the current scope of things...
* Previewrender by the external renderer - especially useful for materials that are completely different from Blender's.

Of course, ideally Blender's internal renderer would be treated the same way the external renderers are treated: with the same api & abstract communication. This would force Blender to be a framework that's less dependent on the renderer and this would indeed make Blender much more suitable for integration in existing production pipelines!!! --[[User:Ewout|Ewout]] 12:53, 8 April 2006 (CEST)

← 古い版	2018年6月28日 (木) 17:47時点における版
(相違点なし)

Dev:Ref/Requests/Render API - 版の履歴

Yamyam: 1版 をインポートしました

wiki>Mindrones bot: Robot: Automated text replacement (-[[doc: +[[Doc:)

Yamyam: 1版をインポートしました