It seems that it is not possible to turn off shadows by using the object shadow block. This is what I did, I placed one sphere and one area light in a scene and rendered, of course you got the sphere casting a shadow. Then I turned off the ‘cast shadows’ and ‘self shadows’ in the object block, nothing changed. The only way to stop the casting shadows is to turn of at the lights, which I don’t want to do. Any ideas?
R
If the object isn’t transparent, give the material a bit ( 0.001) of translucency as this will stop it from casting a shadow.
Now that is weird - thanks for the tip! 
Looks like the refraction switch where 1.0 turns calculations completely off so you need to use 1.00001 or so to make it work…
Not too intuitive so to say.
Cheers,
MoodyB,
thanks for the tip, I was going to use Thomas’ Raytype from his TLHPro shaders (which are great) to resolve my problem. I owe you a beer when you come to London.
edit. That method caused all types of strange artefacts when rendering. But Thomas’ Raytype from his TLHPro shaders worked for me. thanks anyway
R
I guess we can use this until pmG fix the shadow problem & makes translucency inactive unless the material has a transparency value / texture set.
I don’t get that problem? I’ve tried it in a couple of ways and don’t get a crash or even an issue…undo, redo, no problem! Weired.
Yup, all copy or dublication processes generate new objects that you’d have to delete, which is ultimatively just like an undo, but this compromise, even while it’s not a great one, keeps the general workflow faster at this point. However, we’ve been kicking this one around for some time now, because ultimatively we could arrange for an undo that would save and recall entire scene informations and then none of that would be a problem anymore, but everything would be a little more at the speed of most other applications in that regard. I think I wouldn’t mind it all that much, because I actually don’t undo that much in messiah…only tweaks if any and there’s no problem at all. Strange, I know…hmmm…but, yes, don’t worry, this is something we have on our mind.
NOW for the good news:
Shadernode list acts beautifully and straight forward now. If you delete the last shadernode in a material it now stays fine within the material and doesn’t jump to the next one.
New particle emitter visualisation is accurately representing the particle emission area.
Lightcone angle is viewable and adjustable in object-view mode (looking through light in this case).
…and more things, I think…can’t think of it right now…lot’s of stuff.
I’m also adding a new particle force, which is quite fun! 
I’m grabbing the new stuff you’ve listed now and see that we go through it, too! :wip:
I just tryed it again and yes Crash! It happens all the time for me?:shrug:
Did you try to: Chose the light as the goal in the cameras IK-settings then press Ctrl-Z??
/ Svante
Yup, no matter what I do, it behaves perfectly, actually. BUT, I’m working with our latest build, which does have a rather noticable amount of changes and fixes again…maybe that fell under it…hmmm…I still have the previous install somewhere…let’s see…
OMG, you’re right…the 2.4b version does that…how wicked.
Well…
PROBLEM SOLVED, hahahaha…what ever that was. It probably fixed a whole bunch of hidden treasures like that…hehe…traps…sorry about that! Wow, we’re ahead of a problem, that’s amazing…too bad we were behind a little by the time we released the last one, argh! :argh:
But, it’s prettier already, so the next one is yet again :rolleyes: an important step towards ehh…ehh…per…fec…tion…yes, perfection! But well, a step, of course! 
hahaha…if you’re talking about the “ahead” and “behind” thing…guess that would qualify, except that it’s been a choice of words in my case! 
Fantastic news Taron. Thank you!
One thing I noticed when I did the simple test with EasyGlass and Particles here:
is that the circles in the OpenGL view have no real relation to the rendered Blobs.
While I don’t expect the metaball behavior in realtime 
it would be cool if the circles would be closer to the actual size - right now they are much larger most of the time so it is hard to guess how things will look when rendered. Do you think that’s possible?
Thank you and the team for your work. :bowdown:
It appears that you can only see the effects of ‘Raymarching’ if the camera is facing the ground plane. The test I did was to place a sphere and a single light in the scene, the camera was facing front on, 25% ground 75% horizon. Added SpeedHazer, connect SH output colour to colour, add a noise node value to value of SH. Set SH to ‘Raymarching’ and select ‘solid’ and ‘from object’. Could anyone confirm?
R
Taron posted this in another thread, so I guess it’s been fixed.
" It currently only renders against objects or ground and not the background, but the upcoming version renders against empty backgrounds as well… …just like it should’ve "
Cheers for that MoodyB,
I’ve discovered that if you deselect ‘from object’ it works, how strange is that? I’m really just fumbling around in the dark; I wish Taron would give even some basic info like he did with the ‘grid & wires’ shader when he released that. Sorry for my rant.
Thanks anyway.
Cylindrical texture mapping still has issues :hmm:
Textures are rendered as though they are flipped on the x-axis ( when mapping around Y ) :
OpenGL textures dont display properly when you set ‘Repeat Height’ to a value above 0 :
That is until you give the heading a v small negative value like -0.001 :
And lastly, rotating the texture on heading affects pitch, and vice versa :
heading at 25
pitch at 25
