Egor Chashchin
JOEMI
About Me
Since v3.0
EXPERTISE
Developer
INDUSTRY
Film/TV
Connect
LOCATION
Chișinău,
Moldova, Republic of
WEBSITE
Houdini Skills
ADVANCED
VEX | Python
Availability
I am available for Full Time Work
Recent Forum Posts
MATISSE AI Tool Sept. 25, 2026, 8:51 a.m.
Let me introduce my project called MATISSE AI - it is toolset of support template-based AI-assisted image generation. It is introductory video fully describing all features done on moment of publication.
MATISSE AI [www.youtube.com]
It can help you build and control image from shapes, images and ROP-renders or previously done generations. Then automatically get generated imagery form different kind of working processes - like custom direct API call, ComfyUI server or even some canvas-based web-tools integrated directly into MATISSE tool. Also you can transfer generation results further to Copernicus.
MATISSE features complex working with curve-based shapes, some of them are unique and related to my decades of experience with artistic computer graphics tools.
Yes, it is all about control and prediction, as main purpose of tool. Of course, it highly depends on image generation model you use for rendering and it's harness and environment. But this tool is an independent facade for different complex setups which you may implement for your needs, and you may easily switch your backyard generation mechanics. I decide to build it with high degree of integrations in Houdini, but it is not strict bind, just successful collaboration. Tool now is in active developing phase, I have some milestones in it. It is developed not in "vibecoding manner" - all features are controlled, it would be strange to develop generation controlling tool without high degree of controlling its development.
Thank you
MATISSE AI [www.youtube.com]
It can help you build and control image from shapes, images and ROP-renders or previously done generations. Then automatically get generated imagery form different kind of working processes - like custom direct API call, ComfyUI server or even some canvas-based web-tools integrated directly into MATISSE tool. Also you can transfer generation results further to Copernicus.
MATISSE features complex working with curve-based shapes, some of them are unique and related to my decades of experience with artistic computer graphics tools.
Yes, it is all about control and prediction, as main purpose of tool. Of course, it highly depends on image generation model you use for rendering and it's harness and environment. But this tool is an independent facade for different complex setups which you may implement for your needs, and you may easily switch your backyard generation mechanics. I decide to build it with high degree of integrations in Houdini, but it is not strict bind, just successful collaboration. Tool now is in active developing phase, I have some milestones in it. It is developed not in "vibecoding manner" - all features are controlled, it would be strange to develop generation controlling tool without high degree of controlling its development.
Thank you
Sphere is not a sphere. Nov. 24, 2021, 12:25 a.m.
Btw. Arnold7 uses now USD files as scene description and with good degree of success. Yes, there is render delegate, but I hope SideFX will split Karma execution to same branches.
Sphere is not a sphere. Oct. 31, 2021, 11:40 p.m.
You are all right, that it is still developing. But it is developing sensible big amount of time - and doesn't demonstrate still convincing "reasons d'etre".
It is timing about two months of qualified developer to implement renderer adon, which can translate USD data to renderer's API calls. With much more wider range of features supported. All renderer's API's (production used) have similar patterns and subjects of processing. If you need task-oriented extending - ok, you just implement it too, as you will do it for renderer delegate. OpenNSI demonstrates some modern approach and don't offer itself to be "common biggest divider".
I seem Hydra is strange branch of rib-filtering idea, but we used rifs for extending content interpretation, instead of cutting it dramatically.
Very interesting - when Pixar themselves get usd file for rendering - do they really use Hydra? They offer such feature. Do they really cut everything not fitted to hydra pipeline from THEIR renderer? And what customers said about this situation?
All noise, I make is not about defective geometry - I hope it will fixed sometimes - (but H19 will render for you squashed 90-faced eggs instead of spheres while) - now I prepare for possible whole production pipeline and I should explain why "we can/cannot use such modern and fast renderer". And now I faced that I cannot said any calming words. Should we thought about Solaris workflow of go pray for Katana (yes, it used hydra for preview, not more). Or just go and spend two months for translator. (Tamerlane forces his sons "learn languages of provinces you rule - then translators could not lie you".) What else and in what worst of possible moment I will found, that something always known as effectively and robust working - will "just not implemented still"?
I mentioned NVIDIA before - I seem it explains disbalance with USD and Hydra developing - just because NVIDIA uses USD and forces it's development - and they were not interesting with Hydra per se - RTX driver uses it - but they changed sources, so it is incompatible with main developers branch.
Let there be Hydra ZOO! Why not another for SESI too? I can develop another one too, if someone ask.
May be it is simpler just to feed one head we needed then?
(Very interesting, do they have squashed spheres in omniverse marbling demo, or didn't noticed such fact? Or they see this and didn't warn anyone and just threw this primitive from using?)
It is timing about two months of qualified developer to implement renderer adon, which can translate USD data to renderer's API calls. With much more wider range of features supported. All renderer's API's (production used) have similar patterns and subjects of processing. If you need task-oriented extending - ok, you just implement it too, as you will do it for renderer delegate. OpenNSI demonstrates some modern approach and don't offer itself to be "common biggest divider".
I seem Hydra is strange branch of rib-filtering idea, but we used rifs for extending content interpretation, instead of cutting it dramatically.
Very interesting - when Pixar themselves get usd file for rendering - do they really use Hydra? They offer such feature. Do they really cut everything not fitted to hydra pipeline from THEIR renderer? And what customers said about this situation?
All noise, I make is not about defective geometry - I hope it will fixed sometimes - (but H19 will render for you squashed 90-faced eggs instead of spheres while) - now I prepare for possible whole production pipeline and I should explain why "we can/cannot use such modern and fast renderer". And now I faced that I cannot said any calming words. Should we thought about Solaris workflow of go pray for Katana (yes, it used hydra for preview, not more). Or just go and spend two months for translator. (Tamerlane forces his sons "learn languages of provinces you rule - then translators could not lie you".) What else and in what worst of possible moment I will found, that something always known as effectively and robust working - will "just not implemented still"?
I mentioned NVIDIA before - I seem it explains disbalance with USD and Hydra developing - just because NVIDIA uses USD and forces it's development - and they were not interesting with Hydra per se - RTX driver uses it - but they changed sources, so it is incompatible with main developers branch.
Let there be Hydra ZOO! Why not another for SESI too? I can develop another one too, if someone ask.
May be it is simpler just to feed one head we needed then?
(Very interesting, do they have squashed spheres in omniverse marbling demo, or didn't noticed such fact? Or they see this and didn't warn anyone and just threw this primitive from using?)