in preparation for some other things i've created a texture that renders volume data.

just convert your volume data (like dicom files) to a valid a:m .tga sequence (irfanview can do this with the plugins package), then import this sequence and tell the plugin to use it.

it renders pretty fast, but it only offers a resolution of 100x100x100 by now.

the example render shows a ct-scan from a clavicle bone.

are there some people doing medical visializsation with a:m?

here is a very small sample clip demonstrating that the data really is 3d ..

looks real cool, great job!!

Very interesting!

Is there any way to do something a bit opposite of this... take an A:M scene and render an image map that represents the total thickness of objects from the camera view? The result would look like the animation you show.

Now that is pretty cool. I don't know what I'd use it for, but I can almost guarantee I would find a reason .

That's cool.

How many slices were used to create that image?

EDIT: (Oops, found the answer in you first image -151 )

Zpider,

Thanks...I have done some Medical Visualization, but it's always been through my own interpretation of X-rays and such.

I'll need to mess around with this some...

Thanks,

Eugene

the .TGAs have a resolution of 512x512 and there are 151 slices, but the plugin doesnt sample each ray trace from the files, that was way too slow, it builds an internal cache with a resolution of 100x100x100x1 (= 1 MB).

this plugin is actually just a proving device for some concepts i'm working on, for which this low resolution will be insufficient i guess. also i'll add a normal cache to be able to show the scan as a surface, so i'll probably end up with 256x256x256x4 (about 70 MB).

>robert: my plans are going in that direction. not exactly building a map from the whole scene, the resolution would be too low to produce good results, but only parts..

i've now added a "solid rendering mode" to the plugin, which created a surfaced look for the rendered volume data, the brightness value works as a "solid threshold" in this mode.

the attached shot was rendered in under 2 minutes and with only 80 depth steps max.
the surface is looking pretty good, even exceeds my expectations for so few steps.

the further plan is to switch the reading of volume data from file to generating the volume data.

this can be a simple noise function, but i'm rather aiming towards a:m blobbies particles.

in a simple shot (same frame size as shown below) blobbies rendered in just under 6 minutes with only a few particles.

my goal is to drastically increase those render times and once i've managed that, to add features to blobbies.

Sounds extremely cool, Marcel!

this is the first blobbies render that the plugin made.
something is off with the surface normals, but that aside i'm pretty pleased.

Hello Marcel,
Congratulations for this great initiative and the time you take to make very good plugins.

You know my company is only targetting MEDICAL VISUALISATION. The main problem is this very specific field is the lack of precision illustrators make is the models or stills they made.
As I said in a previous post (do not remember the thread - sorry) the bio-visualisation & medical market is devided into 2 fields :
1. The public domain, in wich no deep precision is required : the medical purpose is only the background to make money : TV advertising, Pharmaceuticals Advertising, Medical Periodic Tabloids, pseudo-medical dictonnary for non medical audience, ad so on ...
2. The Physician domain, in wich only precision, scientifically-based informations (based on guidelines) is required. That is the targetted market here at EIKON Medical, my company. The audience are Medical Professors, Professors in Surgery, surgeons, physisians, biologists.

In the first field, the acces to CT-Scan datas is very difficult. Only the second field has easy access to these datas (as I am). These data are based on a single human body : Mister X' body. I mean the data are not genericable, and even if one could consider that a heart is a heart and that its anatomy does not differs a lot from another, the illustrator of the 1st filed would find easy ready-made 3d hearts over the Web to include in an 'over-modeling' process in AnimationMaster. The illustrators of the 2nd filed (as I am) have very few needs to use such CT-Scan based 3D models. Radiologists use A LOT these Models with many many many difficulties (due to computer approximations), and there is no difficulty to get a 3d-surface file from these 3d-volume files.

Some words to give you an serious experience of 15 years in Medical illustrations (starting in 2d and now using 3d A LOT).

BTW : what would be a VERY usefull plugin should be an AnimationMaster conversion of 'cg muscle'. Being able to draw basic (or even more complex) already-rigged muscles onto an armature, and seeing each muscle binding/buldge could help AM to geat one more star. An additionnal cg-skin plugin should be the definitive king-killer plugin . These two plugins (cg-muscles for AM and cg-skin for AM) could obviously help us (at EIKON Medical) but everyone interested in making realistic looking characters and animations in AM.

Best regards,

Alain RIEGER

That's amazing! how exactly is a tga holding the depth data? Is it a seriese of alphas? Awesome work.

How soon do you think regular A:M users will be able to tinker around with this cool new feature?

Alain, so what you basically are saying is that ct rendering is not needed for medical viz .. well, i suspected as much. in my first post i mentioned, this is just the second step towards something else, as you can see in the recent screenshots, i'm now coming closer to my goal.
ct-scans just provided an easy way to get non-regular volumetric data. it would have been nice if someone had a use for it, but if not, thats fine with me too

Dan, the TGAs hold "slices" of a scanned body. those slices show density data, that means a bone will show up as white, air as black. the slices are stacked by the plugin to create a volumetric bitmap.

it might be a while before i'll release something the average a:m user can actually use in one of his projects, but i'll keep posting screenshots.

soon i'll compile a functional ct-scan plugin, post it here and move on to a new thread, as the blobbies rendering doesnt have to do anything with ct-scans anymore ..

I think what you got going here is awesome, but I still don't understand exactly where you are planning on going with this?

rendering volumetric data is pretty much a standard problem. what i'm planning is generating this data instead of just reading it from file as ct-scan does.

there are two projects i'm working on, which will use the code developed here: advanced blobbies (BlobbiesPlus?) and physically correct (within limits) fluid simulations (cfd).

while blobbies are basically particles which need to be "rendered" into volume data and then rendered by the volume renderer, cfd typically produces volume data by itself.

when i say "volume data" i mean 3-dimensional-density-grids.

Nice work Marcel.... Are you thinking volumetric clouds as well?
Very promising, and definitely something to look forward to

John, yes definitely! but i've calculated that application on paper and the way i'd want it (clouds can receive light and shadows) it might be quite slow. maybe with a low-res illumination cache grid for the clouds it will work, but the shadows will lose precision (which is ok for clouds i think).

Marcel,

This is really cool! I wouldn't have thought of the possibility, but now when you have, I think I know how you did it. If that is the case, it is really hard to cast shadows on these blobbies isn't it? Self shadowing would be possible but making other objects in the scene cast shadows on "material blobbies" would be virtually impossible. Right?

For A:M to be able to do realistic general fluids, there has to be a fluid friendly primitive in A:M and there is. A:M already has blobbies, but they render very slow and their behaviour is not possible to control from the SDK. Have you discussed the possibility for you to implement your new blobby ideas in core A:M instead? I think everything would be much easier that way.

Or am I missing something?

Anders,

i actually built a small ray casting (aka ray stepping, ray marching) rendering engine into a texture plugin. the plugin interface tells me about camera position and hit position, so i'm just "virtually" continuing this ray.

one problem is that i dont know how deep the object actually is, so i'll just always cast the same depth (i've worked around this in my Marbles plugin by only rendering the ray "exits", at those points i know the object depth, but that approach comes with other problems).

the other problem, as you've correctly noticed, is the lighting. one approach would be to evaluate lighting (trace a ray to each light) at each ray step. this would be extremely slow, but its not possible with the current sdk anyway.

for the clouds i'm planning illumination like this: i'll have a 3d-illumination cache and use the hchor::intersect method at each point of this grid and for every light source. this is NOT a correct solution (transparent objects will render shadows as if they were opaque), but i think the result will be enough for clouds.

for blobbies i'm not planning to stay with the texture plugin approach until the end, but its easy to test some algorithms this way. martin has been so kind to send me the current blobbies implementation and i think i could adapt this code to invoke my renderer. i could make blobbies fast enough to support more advanced features like surface properties.

i doubt though that you will ever get state of the art fluid effects out of blobbies. from what i've read, cfd fields will be the way to go. the nice thing about my volume renderer is, that it can render both techniques equally well.

that said, there are strong limitations to this technique as well. its fast, because i dont have to calculate any distances, i'm just loooking up values in a 3d-matrix and interpolating them. now the problem is, that this matrix gets big very quickly. it has 4 MB for a resolution of 100 and 4 GB for a resolution of 1000 (not to mention the normal cache i'm using which even has the triple size of that).

This is great news!

I've not heard of "cfd fields". What are they? The state of the art CG CFD is rendered by means of implicit surfaces that are also used for the surface tracking mechanism. Blobbies are in fact a special kind of implicit surfaces, but you are probably right about aiming for the more general kind.

the newest render out of the plugin featuring 1000 blobbies within a cube.
render took about 30 seconds

Wow Marcel, looks great!

Is it possible to use your calculations for SSS? One of my favorite features still missing in the A:M-Lineup ...

SSS:
technically yes, but you cannot use this on modeled geometry, only on volume data, so the sss effect would be pretty worthless.
i'd also very much like to see sss in a:m, but it should be implemented by a hash programmer, not as some kind of plugin.

This is such a fascinating thread to watch - Thanks Marcel for the treat in sharing your thought process. Also very interesting conversations going on between yourself & Anders. I feel priviledged to eaves drop.

thanks nancy

just to show that this thread is not dead, here a little update:

- i have moved to v13
- i have added a very simple noise function to the 1000-blobbies-in-box setting to add some detail

this works out pretty well, i think it will even look better when color detail is added.

Wow, that is going to be awesome when finished.