Thank you eonite:)
I have no direct knowledge of the programming of vue. My conclusion about the 'inherent deficiency' is  based solely on the fact that I saw no node which enabled access to more than one point at a time. I may be wrong - maybe there is a node lurking somewhere that can do something like that, but I havnt seen it.
Of course it is possible for e-on to implement nodes which use multiple map points. If you can imagine it, it can be programed:)
They have already enabled the use of other objects location (external dependencies) so I guess they are on their way.
Interesting about worldmachine's blur. It is not difficult to imagine a simple blur filter (like in photoshop, or similar to nruddock's method) but does it do it correctly for uv mapped objects, with seams? It is possible - after all it (and vue) know how to use the info in the uvmapping for texturing, why not for a bluring node? Still I'll be impressed.

Quote - > Quote - Hm, what about a Gaussian function applied ot it? :)

Good question. Maybe ArtPearl can help...

No help from me I'm afraid. Well, not positive help.
nruddock is absolutely right - there is an inherent deficiency with the fe nodes - they only operate on one point of the map at a time. For any sort of blurring you need to know what the values of the neighboring points so you can average them.  So you cant simply use one node.
It shouldnt be hard to set up something similar to his suggestion - having 4 (or 8) copies of the map each shifted slightly in the u/v directions and add/average them up.
But I dont think that will help the OP.
First, there is a problem at the edges, because there are no  neighboring points, at least on one side, to average. That may or may nor be important depending how much the texture map covers and how close it is to the edge.
What is worse is the area of seams. The suggested method will add and average the wrong values. Next to a seam point there will be points with no meaningful value (possibly white) and adding them  will screw up the blurring. Instead of averaging those points, one should add the corresponding point on the other side of the seam. These will not be right next to each other on the map.
You could easily try this out in a 2d editing program - just make 4 layers with shifted maps and merge them. I think you'll get the same (or similar) unsatisfactory results as you got by using the blur function directly - screwed up seams.
The only way around it that I can think of is to get duplicate regions near seams. Then you can apply the blurring in the 2d application or in vue the way nruddock suggested. The practicality  of this depends on the complexity of  the specific case.
Are you sure there isnt something in 3dcoat that could do it? (never used it myself) because that is the only stage that 'knows' what's on both sides of the seam.
Sorry I dont have a practical/quick solution, maybe someone smarter & more knowledgeable will.

Good luck

oops wrong link in my prev post, I'll try again
Hypertexture and terrain

If you start from there and experiment a bit, you should be able to achieve the effect you wanted.
I certainly didnt read 30,000 books...

There is a tut already about hypertexture and terrains

at geekatplay .
I used hypertextures, with lower density,  to create sets of rocks or splashes
Ella in Mid Creation

Searching for Allies

So it is possible to create very different looks, hard to prescribe parameters to use - depends what you want it to look like. No substitute to experimenting. (admittedly hypertextures are slow to render).

Helle,
There is a new thread for the March challenge - click the attached link in Viv's post:)
Pnina

That's great, thank you everybody!

My suggestion for the next challenge:

"Interaction"  This can be interactions between people (good or bad), interaction with or between animals, and even abstract interactions between shapes and lines between colors... I'm sure people will find more variations.

(Alternatively,  we could have 'i had a dream', which is quite self explanatory)

Thanks again and I hope the March challenge is fun as well.

"Runs and hides back behind the corner"
"Jon, I would have run too. "

Really? Seriously? you have a question/info/knowledge/opinion/comment but you'd 'run away' just to avoid confrontation?
Hmmm..
Thank god for someone like Artur. In my opinion he sees vue with rose tinted glasses because his experience with it was good (and his images wonderful) which annoys me a lot, but what a worthy opponent!

Gill, Seems to do the right thing for me  - sea level at  minus 7 and the clouds still sit flat on the sea. I also tried much lower sea lever (as I said in prev post) and that worked right. Maybe they screwed it up in version 8 (I'm on v7 complete). Of course I dont know why you have a problem, but I wouldnt be too surprised if they got cought by their own lack of consistency. Rutra, -I dont see the logic in the distinction between atmosphere being 'physics' and the terrains being 'Man defined'. It isnt like one could not imagine wanting clouds below the defined 'sea level'. Just an example - the dead sea is abut 400 meters below (general) sea level. Is there any reason why I shouldt have clouds right above the dead sea? Yes, I could change the position of the dead sea level, but then it isnt right in the physics sense. And maybe I want an image with  both the mediterenian and the dead sea, how would I get the clouds at -400m? (and similar situations could exist in sci fi settings). -I dont need a sea object in my scene. All I need is to be able to type in a number that defines the atmosphere altitude reference. It is ilogical to put in an object and hide it just to set a number. Waste of resources (no matter even if it is one poly, it's the principle). -A programs failing isnt measured by those who managed to figure out how to use a feature or overcome a flaw. It is measured by those who encountered problems.( I'm not counting those who didnt read the manual or ignored information within). In this case several competent users didnt get it. Obviousely Jon didnt. I didnt. It seems Gill still has problems with it. If I understand Wabe's post correctly he didnt get it till e-on explained it to him. So there  is a flaw there.  I didnt expect that my workaround suggestion would lead to a heated debate. But it is so depressingly inevitable - if I even hint that vue/e-on is somewhat less than pure saintly white someone will find the need to defend the holly cow... I used to love vue and believe in e-on. Precisely because of that I would point out to them and to users what I find bugged or flawed. I thought it will make a  great product even greater. I got disillusioned, I dont report bugs, I dont post about problems, I dont believe it has the slightest effect on e-on either way. Perhaps it is impossible to make a living by producing software without cutting corners in terms of quality control. They have my sympathy. But they do not have my moral support. People of quality who support them blindly disappoint me. Anyhow, doctor's orders I have to watch my blood pressure, so I'll bow out of this debate. Sorry if that may appear unsociable.

It is the software provider's responsibility to define what the coordinate system is. In real life atmospheric items such as clouds and items on the ground such as mountains, valleys etc. are all defined relative to sea level (as you so correctly pointed out).
In vue they dont bother to indicate what they are using but it turns out clouds are relative to the sea level and whereas terrains/ground is relative to an arbitrary coordinate system.
The ground should not have moved, but it's coordinate should have changed if the sea level is the reference point. The ground was 300m below sea at the beginning and its 200 m below sea at the end.
So  - unlike in real life they have chosen inconsistent definitions. That's a flaw, exassubated by not defining it clearly for the user.
Adding and manipulating an  object that I dont need just to enable a redefinition of a reference point is a twisted way of doing it, from a logical point of view. If a change in reference point is needed it should be done by...changing the reference point. If you cant see that - I wont be able to explain it any better. It is certainly not an obvious way for the average user  to go about it - neither Jon or I thought about it.
You are right that it isnt a difficult issue to fix - either by moving the whole scene or by manipulating a water plane, but it could have been done by allowing negative values for cloud altitudes.

Gill - if I set the cloud layer's altitude to 0 and the sea to 0 the clouds  sit on the sea. Moving the sea up or down the clouds move with it precisely. I'm using v7 complete.
As for bug /flaw:
1.The manual says about cloud altitude: "altitude is pretty straightforward. The slider covers usual altitudes, but any value can be indicated"
It doesnt specify it is relative to sea water, and it  isnt correct as you can not  specify negative numbers.
2.From wabe's posts I figure there might be a way to define sea level in preferences in Vue infinite? there isnt one in v7 complete. Having to do it by adding a sea plane (when I dont need one in the scene) and having to change the location of the sea and hiding it, is a flawed way of setting it up.(actually removing it instead of hiding seems to work too, it rememembers the new sea level).

1. If everything is defined relative to sea level, how come moving the sea up or down doesnt affect the ground position? I had my ground at -300 and sea at 0. Then I moved the sea to -100. The ground stayed in its place(-300) although now it is -200 below sea level. Is that not a flaw?

Whatever their definition of altitude is, it should be

1. well defined in the manual.
2. Changeable by the users without adding and deleting a sea plane
3. Consitant. All altitudes defined relative to an arbitrary point, or all defined relative to sea level. Defining it randomly is a bug or a flaw in their treatment of coordinates.

Quote - ...though it seems so silly that for a scene set in a 3D space that it cannot move below 0...

I agree  - I cant see the   sense in this limitation, whether it is the ground or the sea plane that cause the problem. It is a bug or at the very least a flaw in the implementation.

I encountered this limitation too.  My solution was to select everything in the scene (including lights, camera etc) and move it up so the ground isnt below 0. Wouldnt that work for you?

PS if I remember correctly it wasnt just the clouds but the whole sky that starts from above 0, so if the horizon is visible you would have a gap with no ground and no sky ...

koosievantutte - the last drip - 3 points
three_grrr - winter spring (photo to line drawing) - 2 points
Rerewhakaaitu - ? 1 point

**
**

Attached Link: Claimed and Reclaimed

This is such a good theme, I had to take part even though my entry isnt new... This image came about after a relocation, and thus represents the breakage of the 'fabric of life' due to geographic/social changes.

That is sooo funny!
I suggested this a couple of years ago, when a 'critic group' was established.
It was suggested as an easy solution to maintaining a list of who is in the critic group (ask Karen J. she may remember the issue). Just add your image to the 'critique' category as well as to the application category. At the time the powers that be nearly chopped my head off for the suggestion, saying it is impossible computationally!
This was of course a ridiculous response - and many other sites like redbubble and zazzle implemented multiple categories straight from the word go.
So, thanks Chris for resurrecting the idea, and  it is quite amusing to see that now it is suddenly possible and desirable at renderosity too:)
The ability to add to more than one category should apply both to the software/application and to the genre. Just because an image has 'people' in it, doesnt mean it cant have landscape or be surrealistic.
I dont see why there should be a limitation on how many galleries/genres an image should belong.
If there is, it should be a very large number like 10 or more. Again, before you say 'that's impossible' check similar sites, like those I mentioned.
I'm looking forward to the implementation of this idea!
(and perhaps I should learn a lesson from this and revive other ideas/suggestions I had which were rejected of hand by renderosity :) )