Also why do I read recently always about Lux vs Blender when speed is an issue.
Those are two very different approaches.
Why not Blender vsYafaray or VRay as both can be set to be biased.
In the experimental Luxrender integration with Blender there is an experimental photon mapper in the GI options, so the Lux team is developing biased GI options, there’s even an “instant GI” option which is supposedly an innacurate, but fast solution.
Thanks for the heads up AD!
AD you did not understand my point - maybe I wrote it to complicated.
Everybody talks about Luxrender for high quality work and Blender Internal for speed.
Why only LuxRender? I ask this simply because Lux uses a different technique then Blender.
So Blender vs Yafaray or Blender vs VRay would be more logical since all three engines can
offer the same render techniques.
Uh, since when does Yafaray use the same render technique as BI? :eek: VRay, Yafaray and Luxrender all offer various forms of Photonmapping and Path tracing algorithms. Neither Yafaray or Luxrender offer BI functionality such as renderpasses etc while vray does in some modes. All in all - not sure what you’re aiming at here 
Also there is Lux’s “direct lighting” mode, which is pure simple raytracing (i.e. no GI). Yafaray also has a AO mode, IIRC.
you can now get alpha and zdepth passes from Yafaray so things are progressing in that area
Sure, these are also available in Luxrender (and probably many other renderers too) - I was thinking of the more advanced forms of render passes that BI supports. Object and material ID passes should be trivial to implement in both though - but some of the others are actually artifacts of the “fakery” going on with BI-ish renderers and not easy/possible to replicate in a proper GI setting.
Viator
I am not talking about render passes at all - I was referring to techniques like direct light, ambient occlusion, straight raytracing.
I am getting the feeling many here rather would prefer more compositing features compared to better rendering options.
This looks to me odd because I hardly can imagine that everybody dives into the compositor so much as well as also only because you have a compositor your bad rendering will not get magically better.
In addition the way how Blender splits the render layers can only can mix them together never gave me the same result C4D gave when I touched up the layers in Photoshop. But that easily be my own perception.
The compositor for me is a nice option but first priority is a good rendering engine.
This is like listening to my photography students who state that they can make bad images good with Photoshop instead of learning making a good picture in the first place.
Was anybody successful in using the import command line to convert a DAE into the needed xml file?
I’m currently making some adjustments to improve importing COLLADA from Blender. There will also be a GUI – I hope to have it done tomorrow or the day after, so please stay tuned.
Also, please see my earlier request on this thread – if there is anybody here having difficulties rendering interior scenes with complex lighting and materials using Blender/Lux/YafaRay/etc. and is willing to “donate a scene to research”, please get in touch!
Thanks,
Wenzel
Hi Wjakob.
I was just wondering based on all the work you’ve put into this, do you have any plans to join the Luxrender team after you’ve finished college or even before that, they could use someone like you and already have exporters for Blender and all the major commercial apps.
ah
why not recruiting him for the Blender Internal?
I always ask myself why this resource is not being harnessed.
Where are the issues here? I am seriously interested.
If this is a one man project the results look very impressive
and is it so hard to adapt such a code into BI?
One would think if you used opencollada and blender used opencollada then everyone would get along swimmingly…
You know, Android Dragon gets on these kicks – the current one (for those not paying attention) being that the BI is dead.
Or should be dead or replaced or retired or… something along those lines.
Basically that the BI is persona non grata – this week at least.
I am not sure what you mean - I am not saying BI is dead.
Ton himself states that is not modern by any means and
that it is only usable in certain scenarios plus that he has
a hard time finding a person and not paying a person.
But Uncle fact is that in the recent years everything in Blender
matured drastically but not the tool you use in the end the
render module.
For one who only needs what Blender offers it is fine.
For those who need something more I do not want to say
advanced because GI etc is just a standard by todays means
cannot use Blender.
The current integration of external engines is spotty if best.
So it will be interesting to see where this will go to.
why not recruiting him for the Blender Internal?
It depends on if he would want to do a lot of work fixing and modernizing the foundation of a render engine before adding anything or focus on adding new or enhancing features in an engine that already has a modern foundation (a foundation that doesn’t need near as much work.
It’s spotty because the external renderer api is spotty.
Once someone starts to seriously work on it (with the long promised C api as well as the python one) then is should let external engines fully integrate with blender.
Well, one can hope at least.
I think the current architecture of 2.5 may be enough to bring about a complete render API in python, I don’t know why there should be parrelel C-api’s that mostly do the same thing and would be more code to maintain.
Ace C is speed
Uncle I hope you are right since for some years we hope for this already!
Doing an API in C though would require starting up a new render API completely from scratch, I’m not sure if Campbell or another dev. would be interested in doing that if the foundation was laid and a chunk of the work was done already on a Python implementation.
Python pretty much drives the plugin system in 2.5 as of now, including the plugins supplied that allow external rendering, doing a C-api to have the exact same access python has already would be re-inventing the wheel (re-inventing something already new in 2.5) and a lot of extra code.
I am not disagreeing about the flexibility of python in Blender.
but for complex scene exports a C exporter would simply be faster.