I've got a nice starfield material that starts off with a small b/w texture (like 200x200) and produces a fairly random looking starfield with varying levels of brightness, colors. and density. It can do very large render areas without looking repetitive, i.e. it's NOT tiled. I'm including a small sample of the output here. Given the complexity of the material node arrangement, it renders remarkably quickly.

Unfortunately, the process effectively guarantees that all the stars are only a single pixel. (There are few exceptions, but it's really just two stars on adjacent pixels.) That's fine for the really dim ones, but I'd like the bright ones to bleed over into adjacent pixels, kind of like a glow or lens-flare effect. So, I'm wondering if anyone can think of a way to add that kind of blur as a material-node post-process to occur during the render.

I know that I could just turn the sample into a texture map with some Photoshop mods on it, but it would have to be a big texture, and I'm already running low on RAM for this scene.

Alternatively, I would want to blend in multiple instances of a single larger star, but I can't think of a way to get that without it forming an obvious pattern, e.g. tiling.

Any ideas?

watching for sure. That's pretty cool! The node wariors are sure to appear!

From your description, it doesn't sound like something that can be done, but if you show your node set-up maybe I can come up with something.

Attached Link: http://www.renderosity.com/viewed.ez?galleryid=926597

Here's the node setup. It's complicated, but I've tried to space it out and add some annotations.

The basic idea is to generate a monochrome brightness map and a color map, and then to mix them. The monochrome brightness map starts with a small texture file of a black background a few white dots I did in photoshop. There's some brightness differential to them, but not much. I use random values (noise and cloud textures) as offsets into the source texture. That means that any two adjacent pixels in the source texture are very unlikely to be adjacent in the resulting material. That lets me use the small texture without getting a repetitive texture. It also means that I'm unlikely to get adjacent lit pixels in the resulting image since the odds are just against it. I then mix in another cloud texture to act as a brightness amplifier, making some regions appear empty while others have clusters of brighter stars. The more random that brightness cloud, the more choatic the resulting starfield.

The color channel is generated through a series of cloud textures. I did this as a cheap way of generating a lot of different shades between two colors (e.g. blue and white or red and white) in a chaotic pattern. I could have used blenders with noise as the mixer, but using clouds was a little simpler, i.e. fewer nodes. I then used a tree of cloud textures to blend the base color maps into one colorful chaotic map. The more chaotic the mix, the more varied the colors in a given spot, but there's a certain niceness to having a cluster of blue stars over there and a patch of red ones just a bit over. I found that making it too noisy looked unnatural to my eye.

If I could figure out how to export this into a material file, I'd just post it and let you play with it directly.

So, as you can see, my problem really starts back at the random offset. It keeps my pattern from being repetitive (which I like), but it also keeps me from making some stars bigger than others via the source texture since pixel-adjacency is destroyed. So, that's why I was trying to find a "post-process" solution via shader nodes, one that could work on what is now the final material but prior to rendering it.

What I would have really liked (and might still be able to achieve) is to have a single star texture of a decent size and then map it in many, many times, varying the size, location, brightness, and color -- all psuedo-randomly. But I can't just put in 1000+ 2d-texture shader nodes.

BTW, I have looked at some of the external starfield generators, and they do make nice starfields. However, that means loading it as a texture, and it would have to be a BIG texture. I'm going to be doing a print of this piece at 300dpi, so the final render is going to be big, and I don't want the prominent starfield to be fuzzy with texture expansion. On the one hand, it doesn't have to be perfect, but on the other hand, the tinkerer in me insists that I should be able to make it be perfect.

If you're interested, I posted my WIP in my gallery.

OK, I understand the node set up fine. With such a wide image though, I'm having to scroll my screen from side to side to read every line of text. Any chance I could persuade you to delete that image and replace it with something under 800 pixels wide? I don't need the viewing square expanded in all those nodes and you can put them much closer together without it being harder for me to see what's going on. I wish there were some sort of post processing blur in the material nodes, but there's not. The best I can suggest is to ditch the image map altogether and replace it with something procedural. With the right settings, a spots node (or a few of them layered together) might work, but I think your best bet would probably be an fbm (or maybe I mean the fractal sum - I forget which). You can get it to produce varying size splotches at random on a black background and there's an upper limit to splotch size acording to the scale you set, so you might be able to get something that looks right.

Limitation to this approach is going to manifest itself in any sort of transparent/translucent materials where the background will show up as artifacts on those objects. However, it is an excellent shader! (We just learned this the last two days developing commercials.)

bookmark - this is one that I'm going to HAVE to keep up with.

Attached Link: http://www.zurg.net/dan/posertemp/starfield1.mt5

Ok, I'm making some progress here. I've replaced the source texture with a spot texture and a fractal sum texture and this is what I got. Unfortunately, the "rightness" of this look seems to vary with resolution, so I may have to find a way to factor that into the parameters.

I'll post more when I've got it figured out. The current shader here is posted as
http://www.zurg.net/dan/posertemp/starfield1.mt5
http://www.zurg.net/dan/posertemp/starfield1.png

AKmaterialroombookmark