Deep Space WIPs

[parkdalegardener]

If you want corona info this is the info I am using.



Can't make what I don't understand.

[parkdalegardener]

All right. I'm a dunce. I went over this most of the afternoon checking my work. I know I had the flares working before I sent it to render yesterday so I just figured crappy compression. Not an issue. Everything works till Wizzard mentioned they were not functioning correctly. I looked and sure enough. The bloody things were not growing out of the star and falling back as I had originally set them. I pulled up an earlier save and took a look. Works fine with the untextured spheres in the incremental save. Why do I make so many incremental if they can't help solve problems? At least in Poser I just set an interval and the saves happen automatically. Here I have to remember to save at every important change and sometimes I forget. Ok a lot of times I forget. What did I do in bringing the star texture to the flares? After hours I found the culprit. I undid a tick box on the Regrow in the particle settings when I was working on the star surface because I had too many spheres (flares) visible and opaque blocking my view so normally I just wire frame them. There were so many happening I just killed the regeneration to depopulate the screen a bit because even in wireframe too many random spheres while working on a random sphere make one crosseyed. Again, I allow myself to get lost in the forest because I can't find a tree. Long story short. Got it. Not worth a render as there is little difference from the last render except the flares work as designed.

[parkdalegardener]

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

The flares are a particle system with the required randomness for things like size and rotation of the instance, not the rotation of the instance on the surface of the sphere. That is another system set of calculations using the star surface offset as a marker to input the star rotational vector. If I keep the star at origin then the offset (combine x,y,z) is a regular single number instead of the triplet. It lowers the calculation time. I can run the system in real time on my machine. I output at 25fps but this runs rendered on screen here for me at 60fps fully textured. Allows me to make realtime changes in the viewport.


Poser forces me to spot render every adjustment as I go to make sure I haven't messed up somewhere and what it does to the nodes in the material room is a sin. I have a free script from Structure (I think) that tidies nodes in the Mat room for P11. Never installed it for P12 so I don't know if it still functions. It's in Rendo's freestuff.

[parkdalegardener]

So, I've got this. Or at least as good as it needs to be and maybe a lot more. Frame renders are stretching my time allotments though. Twenty to twenty five frames real time on my machine is livable to work in but production frames taking 20 to 25 seconds each to render is not. The weight is up to 69.5 megs with occasional peaks to 220 megs of RAM per frame which is going to start to add up when additional geometry goes into the scene and more lighting calculations get made. I'm going to render out whatever 10 seconds is sitting in the timeline and we'll take a look.

[Wizzard]

Per frame time is always a bear.  Animating live people gets fun with "Drop your marker tween your feet, bathroom\water break." Poloroid for referance.
This is why most animation houses have renderfarms.
8 )
Cheers

[parkdalegardener]

Yep. This will work. The timings are crazy but I wanted to make sure everything works as expected so they are exagerated and a few pulsed together so I can see variances. This is a background object after all. I have specific flares to use as solar prominences  that blow apart. No point is spending that much processing time for something that won't be noticed in distances.

[parkdalegardener]

Per frame time is always a bear.  Animating live people gets fun with "Drop your marker tween your feet, bathroom\water break." Poloroid for referance.
This is why most animation houses have renderfarms.
8 )
Cheers

I used to have a small rendergarden as Vue called them. That was a while back. I don't do much of anything anymore. I've done professional VFX work in the past and have a couple of motion picture teck degrees from about 50 years ago. As I've always maintained; and those like Agent who remember me from PFD will attest; I'm a technician, not an artist. I just muck around in this stuff for fun. Ten second VFX shots were seldom rendered when I used to do this stuff for a living in the late 70's early 80's. Big budget stuff back then. I render in an hour on a single machine what used to take all night on the 5 i3s that were in the garden.

[McGrandpa]

They definitely came up and subsided that time!   The YT vid shows plasma following Electro Magnetic Lines of Force.   Not a perfect arc of a circle every time.   More like lightning on the desert floor I'd think.   But that you are getting these results in basically nuthin flat, amazing job!

[McGrandpa]

I like your Magnetron star (blue)!  Great looking baby monster!

[parkdalegardener]

Actually I tossed that particular flare and made another with only 6 polys to cut down even more on render times. I couldn't leave it alone as I don't like it. I can do better than that. I want a volumetric corona so something has to give up render time. That something is the flare. The star takes nothing. The corona as I've tested is very expensive.


The new flares are indeed more like magnetic plasma. The entire system has been remade. I gave a thought to Wizzard's idea of disk shaped cards (2 and 3 even 4 dimension) that could be rotated to represent arcing flares. A little node play and the same disk can grab a random texture from the star depending upon it's placement on the surface of same star. Good idea but you get porpoises instead of boils and you still need a particle system for distribution. The flare disk rotation is taken care of by the particle system itself and doesn't need a key frame. Essentially; you use the same system with a different particle. A disk instead of the sphere as the instance. It is a lot lower poly count and does save about a quarter second per frame but it results in a similar unrealistic flare.


The new flare is a bit more complicated and needs a lot of massaging. It is more like a lava bubble that rises out of the star and pops. The massaging comes in as not every "bubble" pops. That and the flare must expand at the base as it expands along the normal. The current key to this is multiple particle systems with single particles so I can manipulate them independently and specifically tune each. That defeats the purpose of what I am trying to do. Make an easy to use, "always on", star that can be dropped into any anim without thought as it just works. I have other such works.


The blue star; or any other colour you want for that matter; is just a colour chip. Pick a colour on the wheel and everything updates accordingly. Star, flare, what have you. I'm wiring it all together with just a few simple control inputs as mentioned earlier.


I'm running out of time before my race. I'll post something later on.