Hi all, new to the forums so forgive me if this isn’t the right place to post this.
One thing holding us back implementing blender fully (aside from the particle system et al) in our effect dept is the lack of openvdb importing and rendering. I know that there was a legacy build done by the nextgen guys but haven’t seen anything further. Getting these imports is a major deal for FX - as an example, as it can be exported in multiple ways, a single use option may be problematic. If you look at VRay’s vdb importer in 3ds max, there’s options on import as to where the source export came from. I also recall this being tackled in the 2018 summer of code but there doesn’t seem to have been any implementation. This is a major thing for everyone in FX and has been requested multiple times. Any chance it could be appended to the mantaflow builds?
Speaking of mantaflow, while simulating we really need to see the update in the viewport. The beauty of the existing smoke sim is that you can play and see the update in real time in the viewport, which is a step up on a lot of smoke sims out there. Caching and playing back is a major step back as productivity really suffers. The big sell I have with the FX team here is that you can see this stuff in real time and their layout and design is so much faster. This is a big step back in productivity imho (unless it’s been recently sorted). Any chance we can just call the last frame and display that while the system is simming the next frame?
Hello there. I am not that experienced in FX, but it appears like the mantaflow realtime bake is being worked on: Sebbas Development Report
I can’t really comment on the OpenVDB stuff though, only that I’ve seen quite some other users requesting support. If it interests you, there was a gsoc project which was aimed at doing that (https://wiki.blender.org/wiki/User:Gskchua/GSoC2018/Final_Report, but it doesn’t seem that active anymore. Brecht (the lead developer of cycles) wrote a proposal a bit more recently (New object types), so I guess you should ask him directly (maybe tag him here).
And, as a side note, because you mentioned the particle system, there is currently work ongoing by Jacques Lucke to replace it by a completely new node based system (there is also UI discussion going on atm, consider adding feedback as long as it’s still in dev phase: Particle Nodes UI).
Yeah I’m aware of the new particle system, however methods of implementation such as the basics of adding instanced or animated geometry offset by the age of the particle / event are omitted or not documented. And that’s the primary issue… there’s little to no supporting sample files for people to bug test or get to know how to use the system properly and how to visualise something while designing your system. Something we did during max development of particle flow which lead to the decent documentation and use cases that accompanied it, however here it’s seriously lacking which is only going to impede growth or adoption of the system. As an FX artist of x-years I was staring at the system and just banging my head on the desk trying to figure out how to get something renderable, even an animated object offset by time. Things like this will deter a lot of people without proper documentation. Tyflow has abridged documentation however as the entire system is based on pflow’s terminology and basic function, it’s exceptionally simple to pick up. As this system is bespoke, it’s a totally different scenario and needs to be addressed at the earliest opportunity - even providing sample files from the developers for us to pull apart and see how it ticks which is what we did during the pflow development back in 2003.
I’m aware of the gsoc 2018 summary but as you mentioned, nothing has been further implemented which is a serious blow and a concern as searching the forums for the past several weeks for a solution, there doesn’t seem to be any traction here unless I’m missing a roadmap within the numerous branches out there…
True, but you have to consider that the new particle system is still pretty early in development, and the UI, as well as the underlying code isn’t fixed and changes from time to time, so I don’t think it makes sense to really develope a complete documentation for it, aside from the proposals and documents Jacques already shared. I think with them, it’s entirely possible to get familiar with the new system. Of course, as it’s still in development, feedback is very important, because it doesn’t make sense to develope a system nobody likes when it gets released, and so, the documentation is useless anyway. And because of that, it’s kinda expected to lack important features, and if nobody tells talks to him, he doesn’t how how or even why to implement it.
(Btw, excuse any mistakes I might have made, I’m a rather inexperienced non-native-english-speaker)
The primary problem is the lack of supporting files that people can deconstruct. Documentation will change as the system develops, however for people to get into the new system, even during alpha builds, one would think that supporting files would be provided I’ve seen screenshots but not much else in the way of providing the user / testers with feature implementation examples and, as someone who has been heavily involved in CG education and tutorial development, its paramount that this is done for a system to make its mark else, like you said, no-one will like it. A system can be as basic or complex as it likes with the UI totally counterproductive, however if sample files are included which showcases its use, it gels the information in the brain a lot simpler than reading a wiki which has information about a feature written by a programmer (no offence to programmers) but little information as to how to implement it into the system to get it to work how you’d think. I tried using the particle system and, to be honest, gave up after 2 days as I couldn’t find any supporting information to confirm or deny the information as to how I’m supposed to create something aside from a basic system.
Pete
PS your non-native English is better than my native English. Don’t worry
I’m also looking for OpenVDB import capability (any volume import at all, but OpenVDB is the standard). I understand that now that Mantaflow is in, the SoC 2018 OpenVDB importer no longer works (not that it was finished but now it’ll be harder) so I’m wondering what the OpenVDB path is. Will Mantaflow enable it at some point? I’m willing to help code it.
(an me in this case also).