Willi

what about cycles renderer. it is open source for a while now...maybe an implementation via the sdk is possible? or as standalone renderer with export plugins?

hi shelton, the plugins are compiled with vs2013. install vc redist 2013 from here: https://www.microsoft.com/en-US/download/details.aspx?id=40784 hope this solves the problem...

did you used the updated version(date 05.08.2016)? i realized this also with c4d.

PointCache Update... there was a little bug, that i now corrected... just download it again...

the "SampleRate" slider does nothing at the moment. the samplerate is hardcoded to 1 wich means that the plugin records 1 sample per frame. by increasing this value, lets say 4, then the plugin would record 4 samples per frame, which ends up in a 4 times slower motion. i made some test with an updated plugin, where the samplerate-slider is active, but i get strange results in 3ds max...

hi folks, just want to say, that we have now a download page on or website, where you can download some cool stuff dor a:m. i hope the list will grow in the future... http://www.soulcage-department.de/downloads/

just found jpatch source code. jpatch is also a spline modeller that can import am models and convert it to other polymesh formats... in the source code there are some hash-patches shape descriptions...all java... https://svn.code.sf.net/p/jpatch/code/trunk/jpatch/src/jpatch/

just had a quick look at the source of luxrender and it provides a lot of primitive shapes like polymeshes, nurbs, catmullromsplines, spheres, nurbs, etc... the hash-splines primitive shape could be implemented in this "shape" class i think, for a programmer...but i think that the hash-splines are licensed, so not open source... the only thing that maybe could work is to convert the hash-splines to polymesh via "IEPoly" with "adaptiv" option...resulting in very very high triangle counts...

@bucket rendering this has to do with multithreaded rendering and memory managment. the render screen is devided in little rectangles(buckets). every processor/thread then takes a bucket to render the image. @third party renderers maybe this would never be possible, because of hash-splines... i think/guess the am-renderer uses its own primitive type (hash-splines) to determin ray-intersections... most of free open-source renderers, like luxrender, mitsuba, pbrt, appleseed, etc, uses ray-triangle-intersection methods...

some wishes: -ability to implement third party renderers via sdk -sun/sky system for the renderer -faster raytraced ambient occlusion (maybe through gpu computing?) (NOT SSAO) -true mutithreaded rendering (not instances) and bucket rendering -better cp weighting editor, maybe paint weights

nobody will use the hires mesh of zbrush. there is always a retopology process in conjunction with all the detail maps to get the final model for the animation process... the bottleneck in the animation-performance is always the "skin-deformer". it doesnt matter if its a spline-model or a poly-model. with a very dense spline-model you have also animation performance leaks. thats why animation studios have several models, like a lowres animation model with only to the deformers parented, cut-out, bodyparts, wich avoids the "skin-deformer", and the hires model for rendering... also its common to use vertex caches, like alembic, after the animation process, to avoid the preprocessing steps for rendering. in a:m you cant avoid the "skin deformer" . you cant parent model parts to the bones... also a imported mdd cache is always applied to all the model cps as keyframes, wich can end up in a very slow animation, when your model contains a lot of detail. the mdd is not dynamcly read from file during the timeline... for a polygon-module inside a:m, i think the things for bringing this up, are more or less there... -a spline model is also a bunch of cps connected together ( in this case with hash splines). lets them connect as polygons... -you can import polygons as props and they are displayed and rendered properly, but you cant edit it, or assign bones to it, or smooth them as subdivisions... -mdd importer/exporter is there (also a selfmade pc2 exporter)

at the moment "Redshift".

https://github.com/jesterKing/CCSycles https://github.com/ShaderManager/MayaToCycles

no. cycles is not my favorite renderer. i meant it more in general. but cycles is open source now...

every 3d-app has its advantages and disadvantages. some has features that other dont provide. there is no "all-in-one-app" out there. and if you use 3d apps in a professional way, you automatically have to use other 3d-apps than your favorite one...and you have to bring your data in and out... a:m´s modelling is great for its internal splines...i like it. but if you dont stay in a "polygonal way of modelling" inside a:m (like not using 5-points, not using hooks, trying to decal without overlapping), you dont get your data out of animation master without rework... concerning rendering, thats true...i am not impressed. its slow (no "real" multithreading, slow AO, slow and not usable GI, etc). in the end of every 3d project, the final image is what counts. to get there i can use other renderers, but those are all based on polygons...and so i am back to modelling, where i have to try to get the spline-based model data out to my favorite renderer... its possible to have a workflow of modelling, rigging, animating in a:m and then rendering in other renderers. a:m provides that tools (obj-export, mdd export, my custom cam-export tools). but there are a lot of things to consider (especially in a production enironment) before rendering the first frame out in that external renderer. @fuchur, @steffen: what you think, is it possible to integrate "cycles renderer" in a:m as a plugin?

i know. but when it comes to hooks and 5-point-patches you get into trouble exporting that... i would love to see a "polygon module" that can handle import/export and be able to apply all the animation features on it...

Just imagine... ...A:M would have polygons and OpenSubDiv.... ...and alembic support.... ...and support of integrated 3rd-party renderers in the API / SDK... with that, A:M could be a serious competitor to all the major 3d-applications out there... A:M has the best data management, animation and rigging features that i ever seen in all the other major 3d-applications. but the lack of not having polygons makes it really, really hard to interact with the other 3d products...

new update. corrected some code and implemented a few controll parameters... example sunsky v0.1

here the update... Physical Sky Update

you are right. have to check the code...

its animated with the location of bremen/germany. no clouds.

hi all, here is a preview of my new shader that i am developing. its a physical sky shader based on "preetham´s" paper. at the moment it is only an ambient shader that can be applied on an "environment sphere" for background renderings. it can be controlled by a light or by date, time, longitudes and lattitudes. i hope it can be also implemented for sampling an ambient occlusion environment, so that we also have one more option in the "global ambience" slot... Physical Sky Update!: Physical Sky Update

hi, i couldnt find the SDK category anymore, so i post it here. can somebody from hash give me a file description of the baked particle files (*.par, *.pai)? i assume that *.par is storing the particle positions per frame and *.pai the particle index number, right? but this files are binary and i want to know how they are written. and is there the possibility to acess particle data via the sdk? my goal is to import other particle simulations from other applications (like realflow, xsi ICE, etc.) another thing is, that the user can not define where those baked particle files are stored. they alway be stored in the application install location in the library folder. even if i change the library folder location in AM, they always go to their default location. this is bad if you want to do network rendering, because the clients will not find the baked particle files. the only workaround at the moment is to copy the baked files to a shared location and then manually open the chor or proj in a texteditor and hardcode the new locations...

make an action of your imported model expand the action, so you can see the "shortcut of your model" be sure "animated mode" is on right-click on the "shorcut of your model"->plugins->import mdd now you have an "muscle"-animated action. go to the frame you want to copy out the keyframes. select cps and edit->"copy keframes" make a new percentage pose on your model. select all cps (or only those that should have a pose-keframe), edit->"paste keframe" voila. you shoud now have a percentage pose...

hi, if you are only doing modelling in max and your partner is doing only the animation part in a:m, you can provide the model as obj for the animation part. all the modelling and texturing will be in max. in a:m he could do all the rigging/setup/poses/etc stuff on the obj and then animating. later he could do an mdd export of the animation, and apply the mdd in max to the model. as i know there is no native mdd importer in max (only pc2), so you have to buy a little plugin (ef9 point oven), or convert the mdd to pc2. maybe there are some free converters out there. this workflow we use already for production here at our studio, and works ok. but if you remodel things in a:m to the imported obj, mdd export may not work anymore, because mdd is saving the vertex-informations of the model (frame by frame).