| 1 |
<!-- $Id: devel_body.part,v 1.12 2005/02/08 08:02:36 paultcochrane Exp $ --> |
| 2 |
<h1>Development</h1> |
| 3 |
|
| 4 |
<hr class="top" /> |
| 5 |
|
| 6 |
<p> |
| 7 |
PyVisi is a very new project (launched in November of 2004) and is under |
| 8 |
constant development. However, any help would be greatly appreciated. |
| 9 |
</p> |
| 10 |
|
| 11 |
<h2>Renderers</h2> |
| 12 |
|
| 13 |
<p> |
| 14 |
Currently only <a href="http://www.vtk.org">vtk</a> and <a |
| 15 |
href="http://www.gnuplot.info">gnuplot</a> renderer modules are being |
| 16 |
used in development, however, the structure already exists for the |
| 17 |
<a href="http://www.povray.org">povray</a>, |
| 18 |
<a href="http://plplot.sourceforge.net">plplot</a> and |
| 19 |
<a href="http://www.opendx.org">opendx</a> renderers, one merely needs to |
| 20 |
write the relevant code (although there is some change going on, so expect |
| 21 |
there to be more objects and methods to come). One can use the |
| 22 |
<code>skel_module.py</code> script in the <code>admin/</code> directory to |
| 23 |
generate the required structure if one wants to add another renderer |
| 24 |
module to pyvisi. |
| 25 |
</p> |
| 26 |
<p> |
| 27 |
Other renderers are envisaged being added to the interface, such as |
| 28 |
<!-- <a href="http://www.rsinc.com/idl/">IDL</a>, --> |
| 29 |
<a href="http://plplot.sourceforge.net">PLplot</a>, |
| 30 |
<a href="http://www.mps.mpg.de/dislin/">DISLIN</a>, |
| 31 |
<a href="http://ngwww.ucar.edu/ncl/pyngl/">PyNGL</a>, |
| 32 |
<a href="http://www.opengl.org/">OpenGL</a>, |
| 33 |
<a href="http://www.renderman.org/">RenderMan</a>, |
| 34 |
<a href="http://www.opendx.org/">OpenDX</a>, |
| 35 |
and more. Once the structure is in place |
| 36 |
to add a renderer module, it is just a matter of writing the code to |
| 37 |
the interface. |
| 38 |
</p> |
| 39 |
<p> |
| 40 |
If you are interested in |
| 41 |
contributing code, grab a copy of the cvs: |
| 42 |
</p> |
| 43 |
<pre> |
| 44 |
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pyvisi login |
| 45 |
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pyvisi co pyvisi |
| 46 |
</pre> |
| 47 |
<p> |
| 48 |
and send patches to: |
| 49 |
<a href="mailto:paultcochrane@users.sourceforge.net">paultcochrane at users dot sourceforge dot net</a>. |
| 50 |
</p> |
| 51 |
|
| 52 |
<h2>Code development guidelines</h2> |
| 53 |
|
| 54 |
<ul> |
| 55 |
<li> |
| 56 |
The names of the autogenerated code objects should have a leading |
| 57 |
underscore to prevent naming conflicts. E.g. a vtk renderer object |
| 58 |
should be called something like _ren, and the render window object |
| 59 |
called something like _renWin (or _renderWindow if you like). |
| 60 |
</li> |
| 61 |
<li> |
| 62 |
Debug statements are useful, and for this purpose one should use the |
| 63 |
<code>debugMsg()</code> function defined in the module's |
| 64 |
<code>common.py</code> file. |
| 65 |
</li> |
| 66 |
<li> |
| 67 |
All objects and methods specified in the API should be provided, even |
| 68 |
if the renderer can't actually produce the relevant output. In that |
| 69 |
case, a warning or error message should be given mentioning that |
| 70 |
such a function is not available/possible/supported by the renderer. |
| 71 |
</li> |
| 72 |
<li> |
| 73 |
Generally speaking the renderer needs a python wrapper, especially if |
| 74 |
it is to be run interactively. However, the renderer could just print |
| 75 |
code output to file for later rendering as would be the case with PovRay. |
| 76 |
</li> |
| 77 |
</ul> |
| 78 |
|
| 79 |
<h2>Pyvisi class structure</h2> |
| 80 |
|
| 81 |
<a href="devel/pyvisi_class_structure.svg">pyvisi_class_structure.svg</a> |
Parent Directory
| 
Revision Log