[Bf-committers] For render exporters

Ramon Carlos Ruiz ramoncarlosruiz at gmail.com
Sun Jun 18 22:12:42 CEST 2006


Hi Alfredo, I you said is yafray is all over the place so I was thinking a
little more will not hurt  . .jejejejeje. the thing is that yafray do not
send normals as other renders so is not a big deal but for pov an others
like mental ray it help a little to use the normals that are already
calculated if no it will be just a waste

Un Saludo
Carlos

On 6/16/06, Alfredo de Greef <eeshlo at yahoo.com> wrote:
>
> Hi Ramon, this was in fact exactly how I did it in the
> early versions of the yafray export code, but as Ton
> pointed out, it pollutes blender code too much, yafray
> or other external render code shouldn't be mixed with
> blender code. As is most of the code still is now,
> yafray related code is all over the place in
> blender...
> To remedy that a bit, I removed the identity transform
> hack (already two years ago now...) so that the export
> code itself now has to take care of the correct
> transform.
>
> Actually, if you wanted to, you could bypass all that
> and use all data as is (I think, not so sure anymore,
> was long ago I tried that), and export a fixed camera
> at the origin, renderman style.
>
> Anyway, all this is why a separate dedicated external
> render api really is needed, which I suppose would
> take  care of such things maybe by flags set up by the
> external renderer to skip transforms, bypass
> subdivision, displacement, object instancing, etc..
>
> Alfredo
>
>
> --- Ramon Carlos Ruiz <ramoncarlosruiz at gmail.com>
> wrote:
>
> > Hi all , This may not be very useful but I was doing
> > some clean up to my
> > povray exporter and I realize that for use normals
> > from VLR_list I have to
> > do a mult. operation with matrix (the same as the
> > coordinates co) and then
> > normalize so what if I do not need to do any matrix
> > operation not even in
> > the co, that will be better so I track the source of
> > my  problems to the
> > convertblender.c in the init_render_mesh and I put a
> > small condition after
> > the matrix assignation in the mat and imat variable
> > and put something like
> >
> > if (re->r.renderer==R_POVRAY){
> >         Mat4One(mat);
> >         MTC_Mat4Invert(imat, mat);
> > }
> >
> > same thing in render_static_particle_system and
> > init_render_mball functions
> >
> > so no more matrix operation on the exporter side in
> > the mesh area. The same
> > thing could be done for yafray. I know that the
> > multiplication of the matrix
> > and the re-normalize of the n is not very time
> > consuming but why doit if we
> > can skip it ;).
> >
> > Un Saludo
> > RCRuiz
> > > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at projects.blender.org
> >
> http://projects.blender.org/mailman/listinfo/bf-committers
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.blender.org/pipermail/bf-committers/attachments/20060618/e6afd6f4/attachment.html


More information about the Bf-committers mailing list