Fantasies Attic
Programs and more Programs => Modelization programs => Blender => Topic started by: parkdalegardener on July 23, 2022, 03:02:08 PM
-
Well maybe the deep space between my ears that keeps them from banging together. At any rate I posted a nebulae frame from an anim I was working on in the gallery a month or so back. That started a conversation in the Coffee Shop. Now I can't post anim WIPs to the gallery as off site links wont work from there. Fafnir's ladies are keeping an eye on me after I ran out of paper and crayons over at my little table in the Coffee Shop. They are afraid I'm gonna start carving rotational vector math equations into the table top with my trowel. That and I'm encouraging others to draw on the walls there along with me. My WIPs are littering the gallery floors and The Nurse is gonna think I'm off my meds wandering the hallways looking for a corner to hide in and play with myself. (No not like that.) At any rate the lovely Aelin pointed me over here to a vacant room where I can hide out and play.
Now; I'm going to work on a side project in here. Not my normal gig. I am using Blender, but as per our discussion in the Coffee Shop; it's concepts and results, not software, computer power, or render engine that we are looking at. We want to build a Deep Space environment. That is the aim. This is not going to be a Blender tutorial showing you click by click how to do make your own. I am just a guy not a guru. I don't care if you draw on the walls in here to show what and how you are doing but NO FULL SIZE IMAGES. If you have something that really deserves to be seen, it probably won't get noticed here. Post it in the Gallery. I'm not about sucking bandwith and bypassing the posting limits here on the Forum. Participation is welcome however. No judgments.
-
Ok. Here is a size and if it's too large TL can let me know. I'm not going over what's happened up till now in detail but, the last thing I did was set up an asteroid field to begin the make up a planetary ring system. I made up a bunch of meteoroids from spheres with a displaced noise texture on them and then hit them with another noise on top to make craters. The meteors were scattered as particles throughout the volume of a torus primitive and given random rotations and scales so as to provide variety. Then the torus containing the particles was set in motion to provide an overall volume and rotation to the particles. We've seen that result.
Looked pretty good. But. There is a problem. We need more details. Rings have collisions between particles. That's where the rotational vector math calculations come from. I don't have a supercomputer and the deep space between my ears can only handle so much 3d vector visualization without running simulations.
It's screaming hot here today and I can only exchange so much heat here before I fry something. The box doing the sims is clocked hot and liquid cooled but climate change doesn't care. That means I went at it a bit differently. The meteors in the following image are the same rocks as yesterday but I reconsidered calculating them in a volume. This is hair on a plane I cut into a flat disk with no center. Have to put the planet somewhere. A noise with a huge amount of distortion was placed on the plane and the hair generated on the vertices instead of the polygon faces.
This should make the math easier doing close up collisions between particles. After all. The meteors have to break apart upon impact in the beauty shots that will happen as our ship (nope haven't made one yet) moves through the rings.
The planet in the centre is only a place holder despite it's rotation. After all, the surface isn't boiling in this image and there are no solar flares. It's just a light.
https://www.youtube.com/watch?v=KKNPyp3BDE4
-
Heres hoping for an arctic cold snap. For heat removal of course. 8 )
I like the look of scale you got. the movement of individual rocks is quite impressive, keeping in mind heat limitations. Sounds like building a comp inside a freezer wasnt that bad an idea, 8 ) thanx for the look in. Cheers
-
I think that the change from volumetric placement of the particles to planar with distortion is the way to go with this. Parallel to this playing around there is a background project I decided upon last night. I am going to turn this into a generator via geometry nodes. In other words a stack modifier that will allow me to add everything procedurally. For this "ringed planet" part of the project I built the geonodes that can display the number and size of rings I wish and populate them with particles (meteors). I haven't got past that yet. I will.
So next up will be the beauty shot collisions. Meteors bang into each other, break apart and the fragments move off in directions determined by the application of the original force parameters. This brings up a need to speak of instances.
The particles are not real geometry. This is important. It means that they are much less taxing upon your hardware than actualized geometry. The simple plane test above has ONE uv sphere that textured with displaced noise to provide shape and a simple voronoi used to add the craters. Slight scaling on the x, y, or z to a couple of duplicates and that group of meteors are used to create thousands of particles. Thousands of particles that are really just the one original. This is good. The bad is that there are thousands of particles that are really just the one original. If I change one, they all change.
Poser people. You have something similar. If you duplicate something in Poser you just reference the original geometry and whatever is associated with it. If I load an object in Poser and repeatedly load that object from Import or Library I can rapidly fill up my available RAM. Load the object and repeatedly duplicate it via menu command and the original you loaded is referenced repeatedly. My RAM load stays low. Unlike Blender though, you can modify duplicates without modification of the original geometry.
That means that in Poser you can also generate a crapload of duplicates upon a plane which you distort with a noise. The same way I did with Blender. Issue in Poser that there is no way to automate the process without using something like Ken1171's Scatter Tool which he sells in two versions, one for P11 and one for P12. They are not interchangable though the results are. I am not pumping his products. I don't know the man and I don't use his tools, but; he has exploited this feature and made it easier for Poser people to take advantage of.
-
This brings us to today's problem. I'm working with unrealized instances for my meteors. How do we have collisions between things that are not there? Stay tuned.
-
Heres hoping for an arctic cold snap. For heat removal of course. 8 )
I like the look of scale you got. the movement of individual rocks is quite impressive, keeping in mind heat limitations. Sounds like building a comp inside a freezer wasnt that bad an idea, 8 ) thanx for the look in. Cheers
I'm waiting for TL's rain. Supposed to come today. The version of that done inside a volume is really what I want, but the math for collisions is tedious so I dropped it to the 2d surface you saw for the math. If I add the displacement of the noise on the 2d plane to the position of the particle on that plane I can calculate the position of that particle in 3d space. I need that to be able to call for a collision. Remember, all this is virtual. No realized geometry. That is why it is so important to be able to know where and two particles are at any given time. Remember; what I do to one, I do to all. This means I will need to make specific particles real before they can collide and break apart.
-
Hope you just get the rain PDG and not the rest of it. Good job setting up the thread... :yesway:
-
In theory, instancing duplicates the object with parametres, weight, collision etc.
At least in "high end" proggies like XSI or Maya, they do that. Then again, both do "realistic" hair simulations after churning away for some time.
Like the differance twixt a 2CV and a Veyron in power. 8 )
Cheers
-
Interesting exercises in real physics, PDG. I like the anim of the ring field particle motion. So, in that one, each particle is a real instance, not duped ? Then will come the orbital path later. Sounds like fun.
-
There are no real instances in any of the posted images or animations. They are all random scale and rotation manipulations of the original uv sphere mesh currently sitting inside the "sun."
The sphere to be instanced inside the "sun" has been given two textures. The first is a displacement/bump to give shape and the second is a surface noise to give the craters.
The best results I come up with are if I place the particles inside a volume. The torus for instance gives me a volume shape that is perfect for orbiting rocks. Random placement inside the torus and then rotating the torus results in a "ring" which in turn gives a 3d environment of rocks in motion around a central point. The "sun". All the particles are in their own random rotations separate from each other and the rotation of the torus.
All that works fine. Perfectly. So I scrapped it and started over. Yeppers. Trashed it. The solution imaged above is a different setup. I want to dump all this together into a single generator for ease of reuse and environmental continuity across shots.
Generators are exactly like they sound. They are stacks of instructions to execute on an item and give a predictable result. Unlike morphs they can create, alter, or destroy geometry.
That leads to where I am now. Eye glazing time:
Using geometry nodes I started with a vertex.
The vertex is moved a distance from world origin.
That vertex was given a distance to travel resulting in a line of fixed length.
That line was extruded on a curve resulting in a 2D disk with an empty centre where the planet, sun, or what have you will go.
The disk is then subdivided.
A small uv sphere was generated at world centre. The particle instance. I leave it there so I know a reliable x,y,z co-ordinate system for the rotations.
Next up generate a particle system on the disk and use our sphere as the instance and the disk vertices as the placement points. One could probably use the faces.
With a known fixed origin (0,0,0) for each instance I can set up random rotations.
A noise texture is placed upon the disk. The resulting distortion moves the vertices of the disk around in 3D space and the instances with them.
Rotate the disk around it's origin and the instances all rotate with it while rotating on their own axis. Wheels within wheels.
The noise texture gives me a reliable positional map of the particles. After all; each particle believes it lives at 0,0,0. I need to keep the math reasonable. Volumetric placement of the particles made that a nightmare when I started to figure out intersections.
-
That is where the generator sits now. I can dial up the number of rings, the size of the ring, and drop a shepherd moon into each gap automatically. Ring gaps only appear if there is something to sweep up the dust and small particles so a shepherd moon just happens. The number of particles per ring is adjustable as is the thickness of the ring. That is the noise offset. The shepherd is just a larger random particle. I generate it on a curve circle concentric to the rings. There is a dial to speed it on it's way around the "sun" if it doesn't appear in your camera view, or make it go away if it is.
The big collisions and resulting destruction is where I am now. Keeping 0,0,0 has been a big help in locating the instance I need to make real but the math is complicated and needs to be adaptable so I can cast collisions where I want them. I have results but I am not pleased. I need a new method to do that. I have a thought. I'll implement it later to see if it robust enough. However, I suspect that I may need a separate system.
It is important to again point out that instances are not real. If they were I would be roasting weenies on my machines and selling the stove for cash to pay the electric bill.
The current issue is identifying a particular instance to make real. I have proximity nodes I can use to tell when collisions are about to happen but I need real geometry in order to use them. Catch-22.
-
Seems to be the fly in the ointment. Too many real meshes and it bogs down the whole system. So how many real meshes are you messing with, and what actually is it calculation wise that is heating up the CPU?
-
CPU is under about 27% load across all cores. Not particularly hot on it's own, but the MB clock, CPU and RAM timings and the front side video bus are all clocked up. It's the temperatures in this apartment. When it's over 30 degrees ambient in here and the air is wet enough to wring out, dissipating heat from the GPU is the biggest issue. I run it at as close to full load as possible. I crank out 4K Cycles frames for these test anims. That's 250 frames at 25fps rendered at 256 samples and a full set of passes. My render times are under 7 seconds a frame. There's your heat. My rent includes the utilities thank goodness.
I am very conscious of whats being calculated per frame. That's why there are no realized instances. True geometry is a killer. There only two realized objects in the scene. The "sun" sphere and a meteor you cannot see because it is inside the "sun". I could move it out of shot somewhere but must keep it visible. As mentioned earlier; whatever I do to that initial meteor happens to all of them. Turn it invisible in the render and they are all invisible in the render. Thus; it is hidden in the central star where it can remain visible, but never be accidentally appear as a wayward object in another angle or a different scene.
Heck; because that particular rock is already a real object. It would be a perfect target for obliteration but that would result in the destruction of the universe. Well maybe not the universe, but most certainly the ring system.
I need two more real meshes. The rock to be obliterated and the rock that hits it. No problem. I can easily incorporate one into the generator by putting them in intersecting orbits. However, for the intersecting orbits to be seen in frame by the camera; either the camera or the orbits have to be artificially manipulated. That defeats the purpose of a generator.
The current setup for collisions I am testing isn't going to work. Well it does work but it too time consuming. Timing tells me that the check is adding .017 milliseconds every test. That is ([.017 ms x number of meteor hits] + [.017 ms x number of misses]) * number of frames = time for bed when you are dealing with 10s of thousands of meteors per frame because any given one could be hit at any given time. It only calculates those within the camera view bounding box s it may not be that stiff. It would depend upon the density of instances upon the ring disk(s) and weather or not they are within the camera view.
-
Oh, Blender has a setting to turn on node timings. That is why I know the cost of what I do.
-
So I'm getting into the weeds. I need a project outline for this. Project outline: Start in the middle. Work outward. Done. Yep, that ought to work.
So: Starting in the middle we need a star. It needs six controls. Colour, size, surface complexity, complexity movement, rotational speed of star.
This is the surface of that star with the controls above attached. The colour is a single chip. In this case orange. Frames render at 2.1 seconds so far. A bit steep but so far I can live with it.
So this is the surface. The albedo/diffuse if you will. It is a 4D distorted noise. 3D noise with the W (time) parameter activated. I'll add the ambient next so it casts light into the aether.
https://www.youtube.com/watch?v=kPP_OxbXi6Y
-
Man I hate youtube compression. The boiling surface of the star freaks it out.
-
The utube compression sucks, but I can see the roiling surface. With high ambient I'll need shades 8 )
So, this is done with scripts? Do this whilst doing that whilst cycling the other?
My experiance with blender was one of frustration, with an odd mix of satisfaction whan something worked.
i really enjoy learning like this, thanx
Cheers
-
That is one busy star surface PDG! Great stuff man. :woohoo:
-
The utube compression sucks, but I can see the roiling surface. With high ambient I'll need shades 8 )
So, this is done with scripts? Do this whilst doing that whilst cycling the other?
My experiance with blender was one of frustration, with an odd mix of satisfaction whan something worked.
i really enjoy learning like this, thanx
Cheers
This star is just noise. No funky scripts or tools. Just plain old every day noise with a musgrave texture over the whole thing to give some 3d depth to a flat surface. The noise is 4D. That means that W (as in W,X,Y, and Z) "direction" is active. The W direction on a graph is Time. That gives me an easy way to animate the noise and the rolling and boiling. System load while rendering is 24 meg.
I'm just sucking back the morning coffee. Should have grabbed one from Fafnir with a bit of Rye in it. At any rate. Ambient, thought about it last night. Do my best work while I'm asleep. More shader tricks coming up. I'm using the object mapping here and not the UV. In other words the object itself is used for mapping co-ordinates not a projection of some type. Planar, box, cylinder and so on. I have yet to give it a go.
The theory as I figure it will to be use the object mapping by normalizing (equalling) the vectors as projected from the object. This will make (I hope) radiating spikes from the center outward of the sphere. This will allow me to make the corona and ultimately the flares and prominances if I take it that far. First up, when I get back to this; is to subdivide the sphere a bit . It is still flat with no displacement or bump.
I make this stuff so that it works by itself and I can forget it once it is up and running. For instance the star texture will move as long as the frame counter advances. No need to do any keyframing or anything else and the shader will work on most anything. I could use something like this as the interior of a volcano in a set of shots somewhere and just forget about it. If at any time the villagers decide to sacrifice the maiden the boiling lava will be happy to oblige and I need not worry about it.
-
Can shaders in Blender be carried over to other progs, like Poser? I know some things work great in vue, some best in poser, some in DS, others in ZBrush and so on. I still like to play in ONE program at a time. When I play in Vue, it always involves vegetation, volumetrics and that sort of thing. Vue's renders look better, to me, than either Poser or DS. So, means my output is all kinds of disjointed and unconnected. Yeah. Oh well.
I am enjoying where all you have gone with this Ringed System thing. Me, I figure that might work best in Vue. And I only have V 6 Infinite man. Shrugs.
-
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.
-
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.
-
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.
https://www.youtube.com/watch?v=XoPfnMagckM
-
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.
-
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
-
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.
-
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.
-
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 :thumb_up:
-
This is what I am using as inspiration for this.
https://www.youtube.com/watch?v=o8GnTWb5vNE
-
I think I am getting close.
-
If you want corona info this is the info I am using.
https://www.youtube.com/watch?v=LkaLfbuB_6E
Can't make what I don't understand.
-
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.
-
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.
-
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.
-
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
-
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.
https://www.youtube.com/watch?v=Vi2ClczgGXY
-
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.
-
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!
-
I like your Magnetron star (blue)! Great looking baby monster!
-
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.
-
This is some cool stuff, PDG. I ain't into the math end of this stuff, and there is PLENTY of that to get into. You're building, and for the first time in my life, I am USING the programs. And, both are GOOD. :woohoo:
I look forward to anything you want to show man!
-
I have some finished and wip stuff on the other box that hasn't been uploaded. I am not able to sit up to do much lately and I can't do this type of stuff with a voice prompt.I'll post more in a bit.
-
Hey no worries man. Don't push yourself to pain, ok? There are days I have troubles too, I know how it can be. And i just got one foot worked on, you got ALL that stuff to deal with!!
-
How ya feeling these days, PDG? WIth winter on ya, the damp and cold and all, I get the need for a shot o Creek now and then!
As Granny Clampet would say "It's fer mah rheumatiz!"
-
A little crispy around the edges. Actually, the building cut my tub yesterday so I can get in and out of the shower. The snow is thick and travel for me comes to an end for the season. If I can't get Ed or his son to give me a hand I'm toast. I can't navigate a snowy walkway any more. If I go down again; I'm not getting up under my own steam and it's been snowing here since Sunday with no signs of stopping before tomorrow or Friday.
-
We're looking at more snow this week too, but nothing like what you're getting. I guess the city has no services for the elderly?