Fujiyama Renderer v0.1.6 released

(L) [2013/06/09] [tby tsubo164] [Fujiyama Renderer v0.1.6 released] Wayback!

Hi there,
I have released a new version of Fujiyama Renderer.
The new feature is support for point could.
Point cloud primitives can be rendered as particles.
[LINK http://fujiyama-renderer.com/]
By the way, I have been getting many emails since I posted the last topic.
They say that if I had written Fujiyama in C++, I would have got more
developers who can help me.
Does anyone agree with this point?
What are your thoughts?
Cheers,
-Hiroshi

(L) [2013/06/09] [tby ingenious] [Fujiyama Renderer v0.1.6 released] Wayback!

Thanks for the update! You have some pretty nice features packed in the renderer.
>> tsubo164 wrote:By the way, I have been getting many emails since I posted the last topic.
They say that if I had written Fujiyama in C++, I would have got more
developers who can help me.
Does anyone agree with this point?
What are your thoughts?
I am not too familiar with the code, but looking at the [LINK https://github.com/tsubo164/Fujiyama-Renderer/blob/master/shaders/GlassShader/GlassShader.c glass shader] for instance, I see an object-oriented design coded in C, which looks a bit odd to me. While I don't think C++ is a particularly nice language, I tend to agree with these people. One feature that I particularly like about C++ is operator overloading, which makes the ubiquitous vector and matrix operations much easier to write (and read!) than in C (or Java for that matter). Modern compilers are good enough to optimize C++ code well, so I can't find a good justification for going with plain C.
Looking at the shaders, I find another design decision that puzzles me -- the imperative shaders. Even production rendering, which is the last to adopt new techlonogies, is now moving toward decoupling surface shading from light integration. My impression is that by now everybody agrees that RSL-style über-shaders are a thing of the past (and even PRMan is moving away from it). Languages like OpenSL or NVIDIA's Material Definition Language provide a better trade-off between flexibility, portability, and maintainability, by making materials much more independent from the particular renderer or light simulation algorithm used.

(L) [2013/06/11] [tby tsubo164] [Fujiyama Renderer v0.1.6 released] Wayback!

Thanks for your reply.
Honestly, operator overloading is one of the things that I don't
like so much. The situation where it makes code more readable is
really rare. Code for matrix operations is usually used in
3D transformation, which I believe most of renderers has it in
transform class/module. So, we end up with writing matrix operations
in only 10 lines out of hundreds of thousands of lines.
(Fujiyama calls MatMultiply() in only 3 lines!)
Having that said, it is true that there are quite a few people who
are interested in developing if it was written in C++.
So, I think I have to consider switching to C++ gradually.
Does anyone has other opinions?

(L) [2013/06/11] [tby Dade] [Fujiyama Renderer v0.1.6 released] Wayback!

>> tsubo164 wrote:Does anyone has other opinions?
Why yet another free and open source renderer ?
I know, it is a provocative question and I firmly believe that every one has the constitutional right to write its own render however I also believe that could be more useful to focus the effort of open-source community on few renderers instead of spreading the man-power over many short-living projects.
For instance, I have directly seen the amount of work required for the development of exporters/integrations (the most important part of a renderer from the user point of view) with Blender, 3DMax, Maya, SketchUp, SoftImage, etc. Having to develop a new exporter for every new renderer it is just a huge waste of resources.
There are, at least, 3-4 well establish open source renderers out there; people should consider to contribute to them.

(L) [2013/06/11] [tby beason] [Fujiyama Renderer v0.1.6 released] Wayback!

>> Dade wrote:There are, at least, 3-4 well establish open source renderers out there; people should consider to contribute to them.
Namely....?
I can think of some... PBRT, Mitsuba, Sunflow, Cycles (? Sorry, kind of ignorant on recent blender development), Embree. Just curious what you are thinking of in case I am omitting any.

(L) [2013/06/12] [tby Dade] [Fujiyama Renderer v0.1.6 released] Wayback!

>> beason wrote:Dade wrote:There are, at least, 3-4 well establish open source renderers out there; people should consider to contribute to them.
Namely....?
I can think of some... PBRT, Mitsuba, Sunflow, Cycles (? Sorry, kind of ignorant on recent blender development), Embree. Just curious what you are thinking of in case I am omitting any.
I was think more to: Blender Cycles (I doubt anyone here want to touch the old Blender Internal Render), LuxRender, Yafaray, Mitsuba, Aqsis Renderer. The all have a multi-year development story and multiple developers. The kind of characteristics one-man project often misses and causes the dead of the project when the "one-man" has something better to do. There have been really an endless list of extremely good renderers that have followed this fate: it is a pit and a huge waste of resources.
The current open source and rendering scene is totally dominated by Blender so, more or less, what does matter is here: [LINK http://www.blender.org/download/get-blender/external-renderers/] (the fact that Blender could use some competition would deserve another topic).
PBRT is there under the form of LuxRender. Isn't Sunflow dead since many years ? I consider Embree more a technical demo and I think it misses a user base of artists (the "real" user a renderer should have).

(L) [2013/06/13] [tby tsubo164] [Fujiyama Renderer v0.1.6 released] Wayback!

Thanks all for replies.
I was just wondering if programming language which a renderer is written in
is a big factor for contributors.
I started it out writing it in C just for fun. Now it's getting bigger and bigger
and more people are interested in it. If more people could contribute to it
with C++, I would switch the language to C++.
However, Dade has pointed out a good thing. There are already good renderes in the world.
It may be hard to find a good reason to make yet another one. In business situation,
this will be a problem. Good thing of open source is that no one is forced to work on.
People who want to join work on it for free. Many great open source softwares are
created by that kind of people:)

(L) [2013/06/13] [tby ypoissant] [Fujiyama Renderer v0.1.6 released] Wayback!

I would not rewrite my own renderer in another language just because some people tell me they like language C++ rather than C. Personally, I write my stuff in C++. But I could just as well understand and write in C if I was intrinsically interested in some application.
My point is that if some people are not intrinsically interested enough to go over the C vs C++ differences, then their fundamental disinterest is based on something else. They would most probably not be contributors anyway. Usually, everybody with the skills to contribute to something like a physically based renderer are busy with some other piece of code they have already invested a lot of time in and it would take some truly extraordinary piece of code to make them switch to contribute to some other renderer. There is a huge difference between people who will tell you your project is interesting and people who will actually contribute.
That said, if you play with the idea of rewriting your system in C++ for your own learning experience, then I'd encourage you to do that.

Fujiyama Renderer v0.1.6 released back

Board: Home Board index Raytracing Visuals, Tools, Demos & Sources