It was done only VUE4.

Very well done! Did you use spheres, or what?

heyas; yep, i can see them. they dont look as annoyingly sphere-like as they usually do, though. good job. :) unless they're rocks.... ;) so what's the trick to getting them to look so nice??

Hey they do look very good. :) I can get decent smoke and mist, but have yet to be able to get clouds this good.

Really nice! Do tell! :)

heyas; better yet, zip up your .vue scene and upload it so we can swi-- er, study them ;)

The little secret is "Fuzziness" feature. I used sample spheres, I have applied them "cloud sphere #4" material and then I have worked (increase) whit "fuzziness" indoor transparency by material editor. That's all. Sorry to my english.

Your English is quite good. Thanks for the details! :)

Now what would be REALLY good to learn is why the trick works with the Vue primitives only, and not with Vue's rocks for instance, nor with any imported model... I wonder if there's some secret E-On's trick behind this... lol

I would say offhand it's probably a simple matter that the primitives are UV mapped differently that, say, the rocks. It seems that the primitives are far better suited to deal with some materials than anything else is, and anything "fuzzy" shows that pretty well. AS for the random rock generator, I have to wonder: Does it work the same as Solid Growth, or are there certain, defined meshes and it just randomly cycles between them all? If they are based on algorithims similar to Solid Growth, that might explain an incompatiple UVW mapping, which the primitives wouldn't have, since they are always the same. But then again, the Solid Growth trees and plants always display their materials properly, though they often differ dramatically in structure... hmmmmmmm....................

mike... havent you noticed that all the rocks look like... well, the same 3 shapes? all mine come out that way, at least :/

But UV mapping is not part of the picture in this case, as no Vue parametric material is UV map based, they are set to be applied with the Vue mapping modes. As for the SolidGrowth output, it surely produces "normal" 3D trees. The leaves are bitmaps UV mapped on planes (exactly like Xfrog), although the Vue maps appear to be subdivided in 4 and probably applied with some random assignment system to different planes on the tree. I can't be sure about the bark bitmaps mapping, possibly UV yes, possibly simple cylindrical mapping. The output polygons size of SolidGrowht trees is surely comparable with those of the tree programs such as Xfrog or Tree Professional. It remains the fact that there is something about the fuzziness parameter that can be succassfully applied to primitives and not to other meshes - at least as far as the clouds materials are concerned. This has no apparent logical explanation (to my mind at least). To find the reason why, further experimenting is necessary, unless some E-On's soul comes up with the reason. :-) That's surely an interesting field to experiment upon and I'll surely do when I have time.

AHA! Bloodsong, I think you discovered my subconscious need to make my own rocks! Actually, they do seem to have a little more variety than simnply 3, but that could be mass hallucination based on the power of suggestion. ;) Intersting, Orio... I have to get my mind out of "polygon mode" every now and then I keep forgetting the advances that are being developed what with transparencies, alpha planes, etc... I think I too will try some experments with various shapes which are polygon meshes, as well as "genuine" polygon meshes of simple, standard primitives, such as spheres. But, are the Vue primitives actually a Vue thing? They're always the same, so is there a way of knowing if they weren't simply made somewhere else and saved as .VOB models? I'm not doubting you, just wondering if it would even be necessary for E-on to have to come up with their own coding for something which is already readily available, such as 3D spheres.

Mike, primitives are easily defineable with mathematical functions. While a complex polymorphic mesh would need a polygon coordinates description (such as the one you can "admire" if you open an obj file in a text editor), primitives don't need more than a short formula to be "produced". To make a rough, imprecise but useful comparison with 2D, polygons coordinates formats such as obj are the "bitmap art" of 3D, while the functions are the "vector art" of 3D... lol! This is to say that I'm almost sure that Vue primitives don't exist anywhere, but are simply generated by Vue's engine form a mathematical function, whenever they are "called" by the user... Having that said, once created though, they should behave like all other meshes in the scene... but evidently they don't, according to the results of the cloud materials mapping... so this is what makes me wonder, if there's something more/different behind all this, that escapes my knowledge and comprehension...

Interesting, again... Here's a little test. The objects, in this case all spheres, are labelled accordingly and all have the "Thin White Smoke" from the Volumetric Materials library in Vue 4 applied. They were all exported as .OBJ, with no external UV mapping The Vue sphere look best, followed by the Rhino one. I know that the Rhino sphere is UV mapped, because Rhino's .OBJ export automatically is. THe one from Amorphium, which is definitely NOT UV mapped, since Amorphium doesn't do UV's can't even be seen, though I assure you it is there, right above the text. I have no earthly idea what's up with the Poser sphere....

Mike, I don't think UV mapping can make any difference here. UV maps are coordinate maps that tell the software "start mapping the 0,0 point of your bitmap on that vertex and with that direction". But we have no bitmap here to map. We have a procedural material. It is indifferent, to the effectiveness and quality of the texturing, whatever starting point it is mapped from. Not just that, but I suspect that, if "procedural" is selected instead of "mapped" (which happens automatically if you assing the cloud materials, as they are obviously preset as procedurals), Vue will even completely ignore the UV mapping information that might be present in the file. There are other things that might be better "suspects", as the normals direction, or the number of sides of the object (single or double) although this last thing too, should be "overset" by the application of the clouds material. Very obscure indeed...

Yeah, actually, I see now what you mean. I'm still thinking of procedurals in terms of texture mapping, even though I do t know the difference. Normals might be a good starting point, which might explain why the Amorphium sphere shows nothing; I know Amorph has certain Normals problems... hmmmm... it is unusual, isn't it, why the fuzzy materials just "take" better to Vue primitives better than to other objects. My only guess now woud be that the procedurals such as the fuzzy ones were specifically designed with Vue primitives in mind, and possiblt the fuzzy materilas were designed with ONLY the Vue spheres in mind. They don't look very good on a Vue cube, for example, though not bad, but not as good as on a sphere.

Actually, that's what they said on the "caption" of materials.... "to be used with spheres"... Still, being a curious being...lol...I'd like to know WHY that happens! :-)

I think it would be great if a future Vue would allow us to apply the fuzzy materials to polygon meshes as well as we can to the Vue spheres. A program such as Amorphium can easily make great cloud shapes. Maybe something for the Wish List for Vue 5....