This would be fantastic for baking projection mapping FX.
It’s just a file format, sounds weird that it should be experimental on just a certain plattform.
Its widely supported by all the major 3D suites out there like Max, Maya, C4D etc. which all run on windows.
Its a very powerful format and offers many advantages over Collada. The biggest being the abillity to use mesh deformations. That enables things like baked fluid simulations in VVVV and other highly complex animations that can only be done with deforming meshes.
Imo it should be really considered to be implented. It’s open source and has a very supportive and professional dev team behind it.
Its currently THE standard exchange format in the VFX industry and probably will be in the future, many major studios are developing on that format.
A lot of usefull information can be found here: http://code.google.com/p/alembic/w/list
Aswell as the source code in the download section.
+1 for alembic
sounds very promising. collada isn’t definetely the ultimate solution. we wanted to do our own 3D importer for quite some time, hence worth looking into alembic.
Sounds really nice, though its not a usable product yet.
I wouldn’t wait for USD to become a widespread and stable technology if they even release it in the near future.
I can only see the benefit of USD if all the 3D tools support it aswell which will also take quite a while after the release of USD I guess.
I’m also not sure if VVVV would be utilized for such complex scenes. I mean Pixar thinks in whole other terms when it comes to 3D scenes, these guys render days on a frame with billions of polygons and thousands of assets.
In that case you clearly need a even more advanced format than Alembic if you want to send an entire scene like that to other tools.
Though for the VVVV world Alembic would do the job just fine imo, you can still export entire scenes with alembic, just not those gigantic and complex monster scenes.
Alembic is great. As a vvvv-rookie but 3D-Vis professional working with Maya/Nuke/etc. I’m pretty sure that Alembic is THE format for (cached) geo transfer now and over the next years.
When you need more freedom after exporting (bone systems, skin weights) FBX is the standart in the industry now, I’d say.
So, Alembix would be great! FBX too ;)
+1 for FBX too, Alembic sounds good too, I’ve never used it though…
Hello All!
I am working on a simple setup where I would need to import a PLA animation into V. OBJ sequence is not a real option as it’s huge (750 frame, 2.6MB/frame and I don’t think I can go lower with the vertex resolutions of the model…)
Reading trough the forum I think the only solution would be Alembic…
Any chance it will become supported in the near future? Or any other idea I could try to get this working?
Thanks!
if your GPU RAM bigger then 2 gigs, you can load whole sequence in to the GPU, i don’t think alembic gonna be supported near future…
there are chances tho…
thanks antokhio. maybe I’m doing something wrong but my sequence seems to load into my Physical RAM and not into the GPU RAM. I use “GeometryFile” dx11 and “GetSlice” running 45beta34.2_x64 with packs-dx11-0.6.1-x64.
Are there any other method I should/could try? How can I check the GPU RAM load? “Memory(debug)” only shows physical, virtual and page.
In the meanwhile it turns out that the sequence will be about 16GB in total… more frames and more vertex in animation… :( with 32GB RAM I can only load 50% of the sequence. will try to upgrade to 64GB and than I hope it will work.
thanks
obj sequence player (17.1 kB)
Hi. Sounds pretty rough. Well That was normally working with enable pin on shader, rather then with get slice. I think it is’t spreadeble in dx11 so you can try to load all the meshes in the shader and do a discard to load everything on gpu, I’ll try to post you something to test. Other way around is to bake vertex cords in to the dds sequence… But I’ll need base mesh and a frame of animation to make you something that works…
Hi guys, any plans news to have alembic importer in v4?
A bump for 2018? I’m guessing the devs are not interested (please pipe up and prove me a cynic though) .
Has anyone researched how big a job this would be? Perhaps we could crowdsource dev$. I’d start with a 600 Euro pledge.
As I understand it it would be a c++ thing, so…
1 Like
+1 for alembic support. Its simply the best and most flexible format for all sorts of 3d-related stuff and almost any 3d software under the sun has support for it.
I am actually more interested in exporting alembic from vvvv, but I guess i’ll just build something for our specific case, where its just some geometry with lots of keyframes. I have built a Maya exporter for vvvv before that just built a Maya Asci file for exporting animation, but it was totally hacked together…
Yeah also much more interested in export then import in vvvv context should mention
anyone with insight in how it compares to glTF? which seems to be the de-facto collada successor and which i understand to be endorsed by everyone nowadays. see this list of available tools for it.
@joreg maybe someone can pitch in with deeper insight, but my understanding is that essentially glTF is an interchange format wheres Alembic is for baking. So while both would be nice it’s not a straight up pair to compare maybe.
gITF isn’t supported by cinema4d which is my prefered 3d tool, it seems more 3d for web, which for some things is probably good, but alembic is supported by all major 3d tools, and is one of those things you can ask a client for, and get something you can open without messing about, and also export to, and your client should be able to open.
To be honest anything your going to use in a realtime engine probably needs to be processed before use anyway to make it lower overhead. Don’t know if anyone has used datasmith for the unreal engine, but it does that amazingly, transfers massice modals and lighting including baking VRay, takes ages however, but if you want an a complex architectural scene it makes a lot of sense, pretty much drag and drop VR.
Alembic is used for million+ vertices baked fluid simulation to be handled between softwares. so if you create a complex morphing Houdini madness and want to man-handle the ginormous result in another 3D package, yoiu don’t have to somehow transfer the procedure of how houdini generated that nonsense to preserve your animation. Now this sounds all good and industry standard handling those in realtime is another topic. Alembic doesn’t care about how you process that data efficiently, they might provide you with sensible data formatting like octree or bvh sorting but other than that of course you have to handle uploading data to the GPU in an efficient way.
Also on a side-note FBX also supports animated vertex caches but again handling them is a pain in the ass. glTF in my opinion is more suitable for vvvv to consume.
Now exporting Alembic on the other hand is absolutely fitting for vvvv, however again I’m not sure about realtime