indeed… it will be cool if/when it happens (exporter). Good things come in due time
The only thing im capable of doing is posting the updates. :o
But i do have a good feeling about this one (Fujiyama)
indeed… it will be cool if/when it happens (exporter). Good things come in due time
The only thing im capable of doing is posting the updates. :o
But i do have a good feeling about this one (Fujiyama)
Added velocity attribute motion blur for mesh objects.
Added velgen tool for adding velocity attribute to mesh.
Fixed a lots of minor bugs and updated documentation.
Cool, looks like it’s definitely coming along nicely
I’m mostly waiting until there’s some kind of realtime framebuffer to take on an exporter. Waiting for a render to finish completely before being able to see the result of changes to lighting, texturing, etc., is unfortunately a deal breaker for me.
I hope the framebuffer changes then,
I wonder how far he is legally allowed to go with this since he likely has a non-competing clause with the engine that Digital Domain uses?
It seems sensible to me that he will stop short of making it a powerful engine for Vfx and movies and mainly gear it for stills because of that.
Dark cloud alert…
jeeez Ace your really bumming me out.
With all due respect, please don’t post in this thread any more. You’re not contributing anything useful; you’re doing the thing you do in other threads pertaining to render engines that aren’t Cycles.
What leads you to believe it would ever be intended for stills? He’s working on deformation motion blur, AOV / Alembic / OpenVDB / deep shadow map support. He just added transformation motion blur. There isn’t even a full global illumination solution yet, because apparently IBL is efficient and effective enough for production shots. His website even says
"Fujiyama is free and open source, distribution orientedray-tracing renderer designed to handle production image rendering.
Why are you concerned about licensing conflicts? In the “Author” section he goes on to say,
NOTE Digital Domain is not involved in this project though we have a formal license agreement. Please do not contact Digital Domain in regard to this software.
If you’d like to contribute something pertinent and productive to the conversation, by all means do so.
Me too! The whole thing seems pretty promising.
Started re-writing sources in C++.
Fixed a lots of minor bugs and updated documentation.
Supports reading *.mesh, *.ply, *.obj, *.mip, *.hdr and *.jpg
directory through Python APIs.
Supports writing *.fb and *.exr directory through Python APIs.
Giving file format other than *.mesh, *.mip and *.fb, you don’t have to
worry about Fujiyama native file format descrepancy saved on disk.
Using Fujiyama native file format still has advantages in terms of
speed and memory efficiency.
Fixed a lots of minor bugs and updated documentation.
Thanks for the update!
My pleasure Atom… its the only thing I am capable of doing :o
I think the next release will prove even more beneficial for a exporter being written.
However , It would take me two life-times to learn how to write one, lol ( programming challenged)
From what I read, Hiroshi would really enjoy a program/artist using his engine.
He seems very good at what he does. Im looking forward to seeing more of Fujiyama.
It’s actually pretty fun to write render exporters, and Python isn’t hard to learn Maybe you should give it a shot!
Thanks for the vote of confidence Joel… I would not even know were to start.
But trust me on this one, its over my head, i am a A+ scatter brain.
It took me awhile to figure out HTML lol
fbview now can show rendering progress by displaying tiles that renderer
finished rendering. In order for fbview to receive image data from renderer,
run this,
$ fbview --listen
This command starts fbview in listening mode. When fbview is listening
(to renderer), it receives images data from renderer. If fbview is
already opened, then you can press ‘l’ to turn listening mode on/off.
To terminate render process from fbview, press ‘ESC’ key. It will wait for
all ongoing tiles are done. Note that if you terminate render process
by typing Ctrl + C in your shell, then renderer stop rendering without
notifying fbview. After this, you can recover by hitting ‘l’ TWICE on fbview.
The broken line along image indicates the status of the fbview.
> gray - listening mode off
> blue - listening mode on, ready to receive data from renderer
> green - listening mode on, in progress of rendering
> yellow - terminating render process, waiting for all ongoing tiles are done
> red - incomplete render process, terminated by ESC key
Since fbview and renderer communicate with each other using TCP/IP,
you need to have propper settings for firewall.
Fixed a lots of minor bugs and updated documentation.
Mesh primitive group has been supported. Different shaders can be assigned to
each primitive group. Shading group tagged by ‘g’ in wavefront obj file is
converted to primitive group in Fujiyama.
Vertex normals for mesh has been implemented. Normals can be cusped at
vertex-shared points.
Fixed a lots of minor bugs and updated documentation.
hi, bingoul, thank you for updating the release information. But currently there is only maya plugins, blender can not use this directly.
One more question, what is/will be the benefit that Fujiyama Renderer provides over cycles/yafray/…?
btw, there is more maya to external render bridges on http://www.openmaya.net/openmaya/mayatofuji/mtfu-about.php
Adaptive grid pixel sampling has been implemented. Up to 66% faster than
fixed grid pixel sampling.
Now with Python API, FJ_LIBRARY_PATH enviroment variable is requried to
set up the paths to the fujiyama library, bin tools, shaders and plug-ins.
This simplifies the setup pipelines for multi-platform environments.
Pathtracing algorithm has been implemented in shader.
Python API has new options to override output image resolution, pixel samples
and output scene descripton.
Added ConstantVolumeShader to re-produce volume_and_bunny.py
OpenPlugin command has a small change with arguments
Removed *.mesh file format from the core library. *.ply and *.obj file readers
are provided as plugins.
FrameBuffer is now ascci file format.