Fujiyama Renderer

Open source ray-tracing renderer.

Maybe some interest for someone, nice features and the developmemt is strong.
As young as it is.

Fujiyama Renderer

Overview

Fujiyama is free and open source, distribution oriented ray-tracing renderer
designed to handle production image rendering.

  • Compatibility - written in pure ANSI C (x)

  • Portability - depends on no external library (xx)

  • Simplicity - requires only single C interface header file and library

  • Compact - the core library is small and easy to embed

  • Open Source - licensed under the terms of MIT License (See LICENSE)
    (x) fb2exr is written in C++
    (xx) some external tools require OpenEXR and OpneGL/GLUT

    Features


  • Platforms

    • Linux
    • Mac OSX
    • Windows
  • Rendering

    • Multi-threaded rendering - dynamic assignement of tile rendering per theread
    • Region rendering - accelerates distribution rendering pipeline
    • Tile based rendering
  • Supported Primitives

    • Triangle Mesh - Compact representation
    • Bezier Curves - Unlimited smoothness subdividing in render time
    • Volume Primitive - Ray traced self-shadowing
    • Point Cloud - Can be rendered as particles
  • Procedure Plugin

    • Volume Filling Procedure - Pyroclastic clouds procedure provided
    • Volume Filling Procedure - Spline wisps procedure provided
    • Volume Filling Procedure - Surface wisps procedure provided
  • File format

    • Original mesh format - ply2mesh and obj2mesh are provided
    • Original curve format - curvegen is provided
    • Original point cloud format - ptcgen is provided
    • Original mipmap format - hdr2mip is provided
    • Original framebuffer format - fb2exr is provided
    • Command-like scene description language - works with text filter tools
    • Python Binding scene description - can utilize control structures and libraries
    • FrameBuffer Viewer - displays *.fb and *.mip
  • Lighting

    • Point light - traditional point light
    • Grid light - typical area light with single/double-sided option
    • Sphere light - another area light
    • Dome light - supports IBL with environment map
  • Animation

    • Camera motion blur - sampling non-linear camera motion
    • Transform motion blur - sampling non-linear object transformation
    • Velocity attribute motion blur (for point cloud only) - useful for point count
      changing geometry
  • Shading and Texture

    • On demand reading of mipmap - unlimited number of texture images
    • Pluggable shader DSO - shaders can be written in C/C++
    • Subsurface scattering - implemented in shader
    • Bump mapping - perturb normals based on mipmap images
  • Acceleratotion structure

    • Grid accelerator - for meshes (dense distribution)
    • BVH accelerator - for object instances (sparse distribution)
    • Object instance - saves memory usage
  • Sampling and Filtering

    • Gaussian and Box pixel filters - supports filter width bigger than 1 pixel
    • Uniform grid pixel sampling
    • Jittered pixel sampling
  • Extensibility

    • Rendering callbacks - 5 points to hook rendering process

http://fujiyama-renderer.com/
Copyright © 2011-2014 Hiroshi Tsubokawa

1 Like

Under development

  • Deformation motion blur
  • AOV support
  • Displacement shader
  • Subdivision surface
  • Mesh primitive group
  • Global illumination
  • Deep shadow map
  • Alembic support
  • OpenVDB support

How funny you posted this yesterday. I just emailed the developer asking a few questions yesterday; I thought about putting together an exporter for Fujiyama, but it might have to wait.

Ohhhh… It would be really great if you did a exporter.

Fingers and toe’s crossed.
Thanks in advance.

I’d need to hear back first. Because of Fujiyama’s rendering pipeline, I don’t believe it’s possible for images to be viewed until they’re completely rendered and converted from an *.fb file to an *.exr.

I’m also not sure yet if exported .obj’s face material assignments are used, or if only one shader assignment is allowed per mesh. If it’s only one shader assignment per mesh, that could mean that you’d have to have one color texture for the whole mesh. That could be kind of prohibitive.

There are a few other caveats at the moment, but maybe as development continues, the documentation will become more comprehensive and I’ll understand the renderer’s capabilities better :slight_smile:

Thanks for your efforts Joel, your very good at this stuff.
wish i could help but i have no skills/smarts. :slight_smile:

I found this site (interesting ) http://ompf2.com/viewtopic.php?f=8&t=1785 with Fujiyama
posted by the author.
maybe another avenue for communication… maybe? or just a good read.

Thanks for the efforts.

Interesting that he’s writing it in plain C as a personal preference rather than C++, I guess that removes the possibility of him contributing code to Cycles.

I wonder how that will affect performance?

Do you mean the possibility of portions of his code being used for Cycles development?

It depends on how easy is it to convert C code into C++, there’s a few things that many C++ coders make heavy use of that simply aren’t present in the other.

Many render engines and game engines these days are written in C++ for reasons of getting as much performance out of their hardware as they can, hence why I ask how it would impact performance.

I was asking because I haven’t heard or seen any indication that he’s interested in contributing to Cycles. He is already working on a personal rendering project = Fujiyama.

Well, that was my personal inquiry not his, just saying that since he hates working with C++ in general, he’s probably not going to contribute to Cycles if you ask him.

He couldn’t even if he wanted to, he works for Digital Domain and had to get special legal permission just to work on his own personal project.

Let’s talk about Fujiyama instead of Cycles.

Hi Joel, I would be interested in what Mr. Hiroshi said in regards to your questions…
im just wondering good or bad.

Thanks.

He said he’s planning to implement multiple shader assignments per mesh, mapping textures to various attributes, a way to view images as they’re being rendered, global illumination, etc.

I like Fujiyama, but I have so much to do that I can’t bring myself to work on another exporter at the moment. It’ll have to wait until I have less on my plate.

All sounds good Joel.

Thanks

:yes:

Fujiyama Renderer v0.2.5(Alpha) Release Notes

New features since v0.2.4

  • Added velocity attribute motion blur for curve primitives.

  • Added option to curvegen to generate hair. ‘curvegen --hair in.mesh out.crv’
    will produce hair geometry based on in.mesh.

  • Fixed a lots of minor bugs and updated documentation.

Features under development

  • Deformation motion blur
  • AOV support
  • Displacement shader
  • Subdivision surface
  • Mesh primitive group
  • Global illumination
  • Deep shadow map
  • Alembic support
  • OpenVDB support

There is a problem with the Windows binary. The file msvcr110.dll is missing. The renderer will not run.

It would be nice if there was an xCode project for the OSX side. That way a layman, such as myself, could build it. Or just provide a working APP for OSX users.

As it stands, I can not even try the renderer out.

can someone post a windows build?
tried compiling and i get errors… (im sure it my fault and lack of knowledge though)
would like to try it. :slight_smile:

ok i found the binary download.
this is in a similar state as embree, it has to be run from the command line
both need exporters.