Deep Space WIPs

[parkdalegardener]

I'd have to look back on an old drive somewhere for Vue. I used to use it for Poser environments but the plugins stopped working sometime in the past and I lost interest.

Same with zBrush. I had an old free version that worked with the GoZ plugin in Poser but a drive crash means, that ; like Vue needs to be reinstalled if I care to use it. zBrush 4R4 I think and Vue were 2018 and 2019 infinite.

I'm specifically using Cycles to do this. Exact translation to Poser node for node won't work. Poser 12 is on Cycles 2. I'm on Cycles X (probably gonna be named 3). If what I've been led to believe is true, the new Poser will have the updated Cycles. Displacement and a few other things are experimental in the version I use but that doesn't mean anything as far as the results shown. Colorramp in Cycles is contiguous where as the colorramp in Firefly is compartmentalized to 4 colours. They can be chained however. Most all the nonfirefly specific nodes work in Cycles as well.


Remember, most of what I do is math and shaders. I just picked up Blender in December. I attempted to wrap my head around it a number of years ago with Hedd and failed to progress very far as it was entirely too alien to my way of thinking. The new Poser will have native unimesh (no I won't get drawn into that debate) and will be directly back and forth with Blender for morph making on figures. In the meantime I have been using a shakey python script that maps the verticies and winding order of a Poser mesh. Welds it and maps the changes. The welded mesh can go to Blender to be morphed and then split back up using the stored map of verticies so that Poser won't freak out when it gets the mesh back. Worked for one version of Blender back in November. Then a Blender update to the OBJ import function broke it in the next version. 3.0 I downloaded Blender to see if I could determine what happened. Ended up filing a Blender bug report on the new Import function and discovered Geometry Nodes. Kinda like old VRML. Points in 3D space manipulated. That I can understand. Nobody else really has a use for them much. Too new. Like Cycles for some reason. Too new for people to grasp. They like EVEE. Fast and fake. Like Firefly or 3Delight on steroids because it renders near real time. Lighting fakes are easy and look good. Automatic bloom is georgous but fake. I could use it on the star image and be done with the whole project.

[parkdalegardener]

Speaking of the whole project. I'm still trying to perfect the corona of the star. That's where bloom, the blowing out of an image due to bright glare; that evee does so easily would come in handy.

The solar flares are test rendering now. They look good but I need to see the animation timings. I reverted back to making the flares as a particle and doing the randomization in size, placement, and rotation on the star's surface. Of course they have to work with the surface rotations as well.

[parkdalegardener]

Well the test just ran. The flares are way too slow and youtube doesn't help a person see what's happening I'm afraid.

[parkdalegardener]

I'll add a few more flares and speed up them up somewhat but this is pretty close. This star is a little hotter than the last star but not hot enough. Maybe one more order of magnitude. The corona still has to come, but sooner or later; my render times are going to go up as well. I can still keep frames between 12 to 15 seconds each render frame but they will double with the volumetrics if I can't make the vector normalization and a radial gradient work.

[Wizzard]

The flares are following the star and the colour is pulsing, a bit, but no rise or fall. random generator for the flares would increase render time too much. Hrrrrmmmmm..... a thought involving discs came to mind but the time increase would be prohibitive. cant tell its been a while since I did animations. Your the resident pro so Ill wait till your next sample. 8 )  Cheers

[parkdalegardener]

Yeah, the instances (flares) are a sphere with a map. Think longitudinal lines on an invisible globe. The globe is then rotated 90 degrees. They float out of the star to their midpoint and then drop back below the surface. In otherwise they rise out of the star along the star's normal till they reach the halfway mark, the poles; then they fall back. The poles are almost white and fade out till they are almost gone at the equator. The angle of random rotation makes it so some flares do not appear to arc completely in certain views. The reason for the "snow at the poles" on the instance is so there is a hot spot where the flare breach the surface of the star. The minor displacement on the star surface hides any imperfections that appear due to the randomness.   

[parkdalegardener]

McG, I took a couple minutes over lunch. This is the base layer for the star shown above done in Poser. Not fine tuned, just off the top of my head. Refinement would make it virtually identical as there are no special nodes involved. It is hard on the head doing this for both programs because the way you construct and read the nodes are  backward to each other between Blender and Poser even though the nodes are essentially the same thing. Oh, and I should have subdivided the Poser default sphere a bit to get better resolution on the noise and musgrave. You get more light from the mesh.

[Aelin]

That's true the star is dark compared to our Sun but after all we don't know all universe. And when our Sun is in an active cycle, the most active regions are often the darkest if I don't make mistake. So our sun is perhaps just on the point to wake up in all directions?
And the corona isn't the thing giving the most of the bright to a sun?
I wish I was able to manage just one program (no matter which one) like you do yourself

[parkdalegardener]

This is what I am using as inspiration for this.

[parkdalegardener]

I think I am getting close.