There seems to be a bug with overlapping particles’ edges? Notice the sharp blocky edgges below. Each contrail is stacked above the others on Y.
Aside from the weird clipping I must say the sub-paticle detail, self shadowing, and diffusion over time look really nice. Here’s the animation.
AH GREAT! I’m just happy I get to see some more stuff being done with the particles!!! I figure you’ve used several particle systems? I think I had mentioned that somewhere down the threads and posts, but we’re still up for the final solution of all particle rendering, which will have a profound effect on the rendering engine, so I believe at least. It makes the renderer behave with multiple particle systems just like it does right now with a single particle system. This not only will 100% prevent the funny clipping that you’ve encountered (which I thought was out, I’m just a little bit surprised, but not too much), but also make it all render just as fast as it does with one system alone. What you could do, if you wanted to, you could make something I had done already. Use an object as emitter that has as many single polygons (or geometrie pieces) as how ever many emitters you’d like to have and then animate them using bones for instance. Those geometry pieces or single polygons would then act as emitters for a single particle system. It would act like multiple systems, but keeps the benefit of running just one. I’d be then completely shocked if it would show any funky artifacts! :eek:
VERY COOL, Though!!! I’m still thrilled and it also looks pretty good!!! 
Solved! Also the difference in orientation between cylindrical and spherical mapping is solved!
OpenGL texture displace is always a funky thing, for whatever reason?! I wished I knew more about that myself, but then with all the different gfx boards and even the differences between models and drivers, it just has to be a real rear-ache. So, I really can’t say anything about the openGL stuff. But the rest is in order now! :wip:
UH, yeah, yessa, yup, that’s not only true, but COINCIDENTLY exactly something I was just dealing with. I mean, I’m playing with metablobs righ…no, no I’m not playing, I’m working hard…yes…and…ah…well, so as I said, I’m making some important tests with the metablobs right now myself, also adding forces that would lead towards the use of them. As we’ve examined the results we also found one other little issue with their shadows, which I believe we have fixed now, I’ll check tomorrow, but I’m pretty sure!
Yes, openGL and metablobs…hmmm…I wonder. Maybe there’s a “simple” approach in 2d for the openGL display to at least outline them a bit more true to their shape. I don’t know, yet, we’ll have to talk about that internally. I’m 100% behind that thought, that’s for sure. Funny that I have to repeat that in the very next post I’m writing, but I really wished I knew more about openGL to help us out there, too. We’ll see. But this one is more than noted, too!
Oh, and thanx, Thomas!!! I really appreciate it a lot! 
Yeah, the threads madness, it’s all a little scattered right now…snippits everywhere. And I truely believe that there’s very little order and my little attempt to introduce it by adding a “little particle” thread only made it worse… :argh: :rolleyes:
Anyway, thanx so much for the great cross-thread-support there…hehe…
Yes, the speedHazer is fixed and so is something else we had deep inside the engine, which didn’t show much earlier…it’s funny how things like that happen. But GREAT! 
Here are some older clips I had done during the creation of the SpeedHazer…
SpeedHazer_sm01.avi (DivX) (this one shows solid volume rendering with noisette and basicShader attached for shading the volume!)
SpeedHazer_rm01.mov (Quicktime) (this is just fog with raymarching and a goofy little robot-leg I did real quick to show a friend…hehe…wicked expressions for the mechanisms, too, but not too careful.)
Taron,
Thanks for the SpeedHazer examples, and if at all possible an explanation of the inputs would be so helpful.
Again thanks.
R
Nice I’m personally not too worried about the OpenGL issues as I hardly ever use them ( came across the display problem by accident )
Thanks for the Speedhazer vids. Good to get a glimpse of that it’s capable of ( 1st movie more than the 2nd one )
Sure, although it will be in the shader docs (eventually, argh), here’s a little bit of info:
Opacity - it’s what it always is, of course…(overall “alpha” of the shader)
Value - it’s now called Density, I’ve renamed it for the next version. This is where you would hook in the textures, like procedurals for instance (noise, noisette, AoN things, but also any form of density source like meta-effectors or textures…anything)
Shading - this is where you hook in actual shading nodes like the basicShader for instance. When ever the density threshold is reached to determin the shell or surface of your volume, it also generates normals, which will then get passed to the attached node (basicShader) to get shaded by lighting, reflections, anything you’d want it to look like. This is what will make the solid volume appear like geometry. Translucency won’t work with it really that well, though, because it still is just virtual geometry, so to say…but extending of the lighting to get part of the translucent effect does work fine…but, uhm, let me know if you find it necessary and I’ll see what I can do.
Min and Max - those inputs can modulate (or set) the min and max distance settings for further definition or animation of these values!
Threshold - modulate (or set) the threshold that you want for the density readout. Kind of curious to make that texturable, too…it allows for a different access to the control of the solid volume shape and animation.
Density - now called Global Density…adjusting the overall density through animation or texturing…I am not completely sure why I was even putting that in, but I really figured: why not!
Top and Fade Top just like Bottom and Fade Bottom allow the texturing of these parameters, which could localize different heights and feathering of the volume…tricky one to think about. Using Y mapped texturemaps or meta effectors would be mostly recommendable for that. It’s the “control-freak” parameter set…hihi…one for me for instance.
Random - Ah…funny…I guess I made it so you could texture the random offset of the raymarch sampling…why? Hmm…keep it organic under your percisely defined circumstances…more control-freak things!
Well, so much for the overview!
The next release is coming closer, so you can savely get used to the new input naming (value-density, density-global density)
Hi,
now that I found this thread want to add a little old timer bug. I don’t now how to repeat it, but happened to me a couple of times in previous versions.
[img]http://www.lucesdebohemia.com/JB/Tmp/MessiahBug01.jpg[/img]
dispite this funky list, you can select a group, but always the same group, I believe it’s the primary group, not sure.
Good luck.
Taron, can something be done to finally get the procedural objects in a working state?
I have no clue what the problem is with them, but if they can’t be fixed once and for all, could they be removed from messiah or replaced by simple poly objects?
This is such an old “Trauerspiel” since everybody tries to use them for rendertests and is getting errors like in this thread:
Good luck, young skywalker 
HAHAHA, do you have secret microphones hidden in our offices? That’s just weired, man!
Fori and I had been talking about that a few weeks ago. We’ve looked into that section and found some wacky stuff…the mapping for all types appears to exist, but the intersection routines where never written. So we’ve actually talked about exactly what you’re saying to maybe just replace the with polygon objects, which would make them also completely compatible with all the shading, or really just to remove them. Funny.
I really don’t think they’re necessary unless they are shapes for the metablobs, which would be funny then…but just like that, unless they were working with backsides, there’s no use for having them.
It’s not the top priority and we havn’t yet made a decision, but it’s definitely a topic. Maybe we just drop them until we know what we want to do.
Thanx for the reminder, though. But it’s really freaky…very strange. :eek:
Great!
It is good to know that you have the same concerns.
IMO the procedural objects are the most abdicable feature of messiah, especially since they don’t really work in the only situation they would be convenient for - fast simple render tests.
The “Ground” surface in the camera is a fantastic timesaver, but the procedural objects have little use IMO.
Replacing them with polygon objects from an “objects” folder in the “modules\defaults” hierarchy could be a nice way to have basic custom objects right at hand, but even removing them completely and never talk about them again would be fine with me
I am very happy that you finally go in with the knife to get rid of the irritations! :applause:
Thank you for your response.
Cheers,
I had the impression that they were originally there as shpaed nulls for rigs. They also had some projection mapping funstions. But you’re right - they have to work in renders.
Cool to see these things being taken care of.
You are right - now I remember.
For rigs I don’t think they are really “important” - don’t know, never used them.
The mapping is a different topic. I personally find it absolutely weird to use them for mapping or weighting, since they are “visible objects”. From day one I thought this to be the wrong way to go.
For mapping, a visual cue with a grid in openGL (similar to Cinema 4D for instance) would be way more helpful. I would love to see it implemented in a way, that as soon as a texture map node is active, it’s accompanying “texture grid” shows up in the world view (as a plane, a cylinder or a sphere etc.). It should show rotation/scaling and position - direct manipulation would be killer but I could live without it. In Cinema 4D, mapping was so easy since you were able to see your mapping in space and manipulate it like any other object.
The procedural objects try to do the same, but are somehow weird and don’t feel right to me - they live in a different “space” from rendering.
I don’t think anyone likes them?
For weighting I find metaeffectors okay, but procedurals weird again. In the end - give me good weightmap support for rigging and rendering and I will be all fine.
Since this feature is needed in messiah anyway to make it a considered tool in games or many other pipelines, it would be a AAA priority for me.
And don’t get me wrong - I don’t talk about replacing the current “non-weights rigging” with making weightmaps mandatory for everything, but for certain riggs, all games and also rendering, per-point weightmaps are very useful or simply needed.
Just my half a dime 
Cheers,
Amen. Alone for soft-body effects. you just can’t do nooks and crannies with meta-effectors and remain sane.
Not sure if this is a bug or a request:
when you make a preview, the camera aperture is ignored. I know there are codec determined proportion issues for the avis - but could we have at least the greyed in aperture mask in the preview?
David
When using a procedural as a ‘tool’ mapping type for a texture - i.e as a simple reference object - it will not recognise any motion changes on the object the texture is applied to from its loaded-in position / rotation ( this REALLY tested my patience last night :banghead: )
I’ve attached an mpj showing the problem. Use these steps to replicate it :
Go to frame 97 and render. Remember where the black box is shown on the road surface
Now rotate the Road object 180 on heading and move it -4 on z ( doesnt matter whether you do this in animate or setup mode, the result’s the same ) Now render again. It’s still in the same position, nowhere near where the actual procedural object is :hmm: