Working on a asteroid/comet generator thingy to go with my stars generator.
All procedural and stuff. Basic crater generator I made. Atmosphere/dust is constrained to planetoid body.
Wow this looks fantastic! :o
Could really be a photograph taken from a deep space probe. A few craters seem to stretch a bit but it is totally forgivable and would probably even be possible in real life.
Awesome!
How many NASA's asteroids images were you seeing today?
Jordan: yes. ;D
Nice work as usual, i'm really curious about the dust/atmo constrained to planetoid body. need a hint there...
Quote from: Ariel DK on September 09, 2020, 12:36:40 PMHow many NASA's asteroids images were you seeing today?
Jordan: yes. ;D
Nice work as usual, i'm really curious about the dust/atmo constrained to planetoid body. need a hint there...
Check this out Ariel DK. It's just Altitude offset with desires depth and stuff.
Thanks for the comments guys, much appreciated. I want a little more roughage and detail and I think I'm getting somewhere. And yeah, the redirect to really give the planetoid body some kick does seem to stretch and warp the texture coordinates, could be realistic. Not noticeable in other seeds so far, just this one, but I did kinda like them, like it was rotating into impacts.
Quote from: WAS on September 09, 2020, 12:48:51 PMCheck this out Ariel DK. It's just Altitude offset with desires depth and stuff.
Ahg... simple and clean. i made a quick try to this before, without to much success, i can't find the file right now. thank you btw!
Looks great indeed.
Great rocks. I do hope they keep well away from earth.
Yeah especially one this size, not quite dinosaur killer size, but at 50,000m (50km), we still wouldn't want it coming close to earth.
Same geometry as A2 WIP, but this time there is texture coordinates which fixes the crater stretching with the terrain, and I've added a lateral offset to naturalize the shape imo. Changed some surface shaders a bit too.
This version isn't PT. Last is. I don't see too much of a benefit with PT here, and it goes from an hour and a half render to over 9 hours with PT (at 2440x2440 MPD 0.7 AA 7).
Looks very much like photos.
I tried to take this to a large astronomy group. Let's just say only a small percentage thought it was photorealistic. I did get some good pointers though. Like for one, remember to disable the second sun xD
QuoteLet's just say only a small percentage thought it was photorealistic.
Interesting. Your renderings look amazing to my untrained eyes. What were their objections?
Quote from: sboerner on September 10, 2020, 06:15:39 PMInteresting. Your renderings look amazing to my untrained eyes. What were their objections?
The lighting was the first major issue. Forgetting to turn off the second sun.
A lot of people liked the high detail but noted without any lens issues it was easy to tell it wasn't from NASA or anything like that, though one noted it would be realistic for the naked eye/movies.
The Orthographic render seemed to trip some peoples perception of the geometry which gave them bad impressions of the lighting model making them feel it was off.
I addressed the lighting issue and added some DOF based on the depth of the planetoid (did it in post cause finding the distances in TG was proving ridiculous). Does look better imo, especially having the second sun off.
I have kinda mixed feelings. The last one might be more realistic maybe. But i like the other versions too. But this ones looks good too.
I agree, actually. I liked the subtle lighting wrapping around it more than the hard cut-off from a single sun. I actually excused away the last ones by saying "Maybe it's close to earth and getting some backscattering [or planet shine, whatevet]" lol
I really want to rotate this thing and do a video or GIF but, I can't seem to. When I check rotate textures and such, the geometry of the planetoid doesn't rotate, neither do the craters. Still haven't figured out why.
I used only transform nodes when i had a similar problem i think.
If i remember right Ulco said to use a Simple shape shader... Not sure.
I will have a look at that thread.
This one:
https://planetside.co.uk/forums/index.php/topic,18917.msg184668.html#msg184668
Hmm I'll have to give that a try. If not I think you gave me idea to use similar, but convert all the data to scalar, and rotate that and the colour shaders seperately and recompile.
If it gets too hard just move, rotate your camera if possible.
So a transform input shader doesn't work, either with scalar or regular. It just seems to move around the noise creating a liquid blob liken effect, it doesn't rotate at location. Very strange.
I would do a rotation of camera but I think I'd need to setup a rail system elsewhere and I'm not even sure where to start there gotta learn about cameras in blender or something.
Point zero problem maybe?
If your object is outside 0,0,0 first transform it to there and then use another transform node to get the desired move.
I think we talked earlier about something similar...not sure.
That could be. It's at default location ratio. So polar boundary box is at 0,0,0 (50000m radius at 0,-50000,0 location)
Rendering out the blob in 360 just to see how silly it is, than will zero out the loc.
I think your scene will work.
If not then i can do the camera move if it is not complicated by the way.
Just a very basic scene would be enough you know.
Weird. So it must be some sort of shader issue. It does look like the main geometry displacement is rating, but everything else is translating out of scale or something weird.
I was hoping to just be able to look at the thing in 360 from a stationary camera. Curious what the issue is. Texture Coordinates? Seems they break intersect underlying too. Hmm.
It's weird the craters are acting like they are in final position, without it being used (besides the end transform node), and I was sure, and checked, that I was using Get Position in Texture.
Can't say much about in general. But you might get the craters at least moving like you want by using a SSS like Ulco said.
If there is a big crater that could be a problem too by the way.
I'm not sure I understand the simple shape remedy? Just like, add one after the craters displacement? The craters are voronoi vector based with the add scalar method.
Texture coords aren't the issue, though without they the issue seems worse.
Quote from: WAS on September 11, 2020, 12:12:42 AMI'm not sure I understand the simple shape remedy? Just like, add one after the craters displacement? The craters are voronoi vector based with the add scalar method.
Mine were just standard craters can't say if it will work for you. But yes just put a big simple shape shader after the craters.
I'll give it a shot, can't hurt. I feel like I'm doing something wrong but I just can't spot anything. It "should work" by what I can see but I feel I'm overlooking something.
Anything animated by accident? Like the 4d noise for example?
No. Just checked the shaders in play. This is so strange.
There is better colour continuity on some of the masks and stuff. I'm at a loss. Oh well I guess.
Wonder if distort by normal, and warping masks by the terrain is the issue, if so that's sad as you'd think they'd all respond to the final position call.
You wrote you had a final transform set to world. I immediately thought that might be the problem. Or any XYZ shader? It secures everything in place.
Just woke to see this thread again, and it looks very good as a still, btw. I liked the 'glowing' version, but indeed, the blacked out one is probably more realistic.
There is a redirect shader, indeed. It is the second shader which varies up the base planetoid displacement. Then the Compute Terrain. That has a patch size of 1000.
I tried with no redirect but hmm, still same deal. Some shaders just act in final position and won't rotate, without there being any transform shaders (except the last for rotation), or craters using Get Position (instead of Get position in texture which does allow rotation)
1. Tex Coords From XYZ will need to be disabled (there are two of them). They wipe out the transform on the shaders that follow.
2. There is another problem which I haven't figured out yet, but I've narrowed it down a little.
The following works:
- Connect the craters layers directly to Base Colours
- Disconnect the input to the craters layer
Something in the input to the craters layer is causing the transform to be lost. To narrow this down further you could reconnect those inputs one until it breaks.
Texture coordinates is probably no biggy. I never honestly inspect the differences often, just hope it "understands" the terrain better.
As far as the craters, that is strange. Is it the repetition of the phases utilizing the transform shaders? None of the transforms use world space, but I have noticed doing "scales" like this in steps does slow things down significantly if what you are working with is complex, which is why I rebuilt for this setup exclusively because my other procedural craters with ejecta and all that is extremely slow. I wonder if it could be the bias part of the craters (which is why they kinda look weird as the terrain moves). I did notice with other shaders with info below/above 0/1 it will clamp the data forn some reason.
So I did some tests, I disabled the craters and the texture coordinates but I still see a lot of rolling textures and displacement from the surface shaders. Do notice the area that exports bad with the micro exporter does have issues in TG too without the craters and texture coordinates. So must just be a disp issue and can try diff seeds or something.
Can't tell much more without a file, but I guess Matt's on top of this.
3. There's also a Compute Terrain which will need to be disabled.
4. Redirect Shader displaces along world spaces axes, so that won't be rotated.
5. Using the planet's built-in rotation will produce better results than the transform shader because the micropolygons will move in sync with the textures.
Hi Matt. I had in the past problems with the planets build-in rotation-moving.
Are there sometimes cases with some nodes that this doesn't work and with other combinations we get then and now problems too?
Would you agree if i said we need some kind of better-easier working as intended related to other nodes (not sure how to write this better hope you understand) when moving rotating objects, textures, shaders etc.?
Quote from: Matt on September 12, 2020, 04:16:49 AM3. There's also a Compute Terrain which will need to be disabled.
4. Redirect Shader displaces along world spaces axes, so that won't be rotated.
5. Using the planet's built-in rotation will produce better results than the transform shader because the micropolygons will move in sync with the textures.
Ah, so in other words this is all broke...
I have to sacrifice every defining aspect of TG making a nice surface. Seems buggy. A gray block is definitely not an asteroid xD
I can't even see all these bugs making a good real-world planet to spin without using just height and color image maps. In which case TG isn't doing really anything special but the atmosphere node (compared to other applications; though Blenders atmosphere mocks seem very good)
:(:(:(
No it's not all broken. "A gray block?"
You can retain almost everything that makes your asteroid look the way it does.
I think all you need to do is disable the Tex Coords from XYZ nodes, replace Compute Terrain with Compute Normal, and do something different in place of the Redirect Shader (e.g. a vector displacement with a rotated vector) if it's necessary for the look. Please give that a try before fearing the worst.
It would be great to have some way to rotate these displacements globally and I'm thinking about how I'll do that. It is not simply a matter of changing the texture coordinates, which is all the Transform nodes are designed to do.
I meant "gray blob".
I got some ideas, but when I disabled all that stuff I was still having issues with all the surface stuff with it's masks.
Also for the redirect wouldn't you just rotate each channel before applying the redirect? Not sure how it works exactly. But since this is just on X would using a scalar, and rotating that accordingly before applying to the redirect work? What about the warp input and a vector disp on X?
Idea I meant about warping:
Only issue with this approach is it doesn't really change the geometry up from being spheroid.
Redirect to X means "displace along the world space X axis" or in other words "move the vertex's X position in world space." So that will not make sense with a rotated object.
You need a Vector Displacement shader where the input vector itself is rotated.
OHHHH! It's literally warping world space (which is what we want to happen at the end of the chain)? Do I understand you correctly?
Warp Shaders don't change the displacement vector, they only change texture coordinates, but that doesn't change the direction that something is displaced in.
Quote from: WAS on September 12, 2020, 03:08:10 PMOHHHH! It's literally warping world space (which is what we want to happen at the end of the chain)? Do I understand you correctly?
I'm not sure, it depends which nodes you're talking about.
The redirect shader on the planet.
Still seems to be some rolling surface displacement, but getting there.
Quote from: WAS on September 12, 2020, 03:19:52 PMQuote from: Matt on September 12, 2020, 03:12:28 PMQuote from: WAS on September 12, 2020, 03:08:10 PMOHHHH! It's literally warping world space (which is what we want to happen at the end of the chain)? Do I understand you correctly?
I'm not sure, it depends which nodes you're talking about.
The redirect shader on the planet.
The redirect shader allows you to displace along the X, Y and Z axes (in world space) using whatever displacement shaders you plug into it. As opposed to just displacing in whichever direction the displacement shader wanted to displace (e.g. the surface normal).
Quote from: undefinedStill seems to be some rolling surface displacement, but getting there.
Way cool. 8) Getting very close.