There just happened to be a candle flame on a YouTube video I'm half-watching, so here's a real flame for comparison:

Still noticeably different.

And the wick's completely black. Did a google image search and I've no idea where I got the ide the wick inside the flame is white ? :oS

The first time a candle is lit, the wick will be white for a time during its burn-in period.  Afterward, it will be completely black throughout its life.  A well-cared-for candle should never have a smoke trail; smoke trails appear when candles are relit with rather long, unkempt wicks.  They don't last long as the flame burns but they don't look pleasing.  Tha's why you should clip the wick shorter before relighting a candle.

This is like a new WICKipedia, hehe.

I managed to find my matmatic sources in an old dropbox folder. The rgb method was introduced in matmatic 1.7. There were several changes to make it easier to create colors either using integers or floating point numbers and not have to keep changing between Color and IColor. As well there were changes to make it optimize smarter, where sometimes a node network would be generated, and sometimes simple constants.

----------------------------------------------------

Matmatic 1.7.0

----------------------------------------------------

Added AmbientOcclusion parameter EvaluateInIDL.

Added PoserSurface parameter Gradient_Mode.

Added function rgb - constructs a color from three components. This is a smart function to construct colors statically (at compile time) or as nodes during the render. If any component is a node, a UserDefined node is created. If any component is a float, then Color(r, g, b) is returned. Otherwise, it returns IColor(r/255.0, g/255.0, b/255.0). Thus it is possible to express using either 8-bit (0 to 255) integer style or floating style (0.0 to 1.0).

Added function max(*args) - returns max of its arguments using compile-time math or numeric nodes or color nodes

Added function floor(x) - can take numbers (returns math.floor(x)) or nodes (returns Floor(x)) - thus it does the right thing.

Added function hsv(hue, saturation, value) - returns an rgb color (interprets int value as 0 to 255, float value as 0.0 to 1.0). This function will produce an exact color of all three inputs are known at compile time - otherwise it will create a node network that does the job at render time.

bagginsbill posted at 8:53 AM Fri, 13 May 2022 - #4438554

I managed to find my matmatic sources in an old dropbox folder. The rgb method was introduced in matmatic 1.7. ..

Any chance of getting hold of 1.7.0 ?

VedaDalsette posted at 1:11 PM Tue, 10 May 2022 - #4438409

This is like a new WICKipedia, hehe.

It struck me because I noticed that the ensd of the wicks were glowing in this one. I wonder if that's because they're newly lit as hborre suggested or because of the type of fuel/wax ?

I'll check on that.  I burn candles on a regular basis just to add fragrance to the environment and relaxation.  ATM, I am using a soy-based wax but I don't think that's the reason.

Bagginsbill posted a similar but different picture showing zones a while back. What you found explains why the tip of the wick is sometimes, but not always, bright orange.

I found two more nice candle flames in videos, but rather just post those screenshots I've combined them with a few previously posted images.

Not surprisingly I think bagginsbill's latest version (bottom right) is the best of the Poser attempts, although I think that the wick needs to be longer and black (not white) - but that's the fault of my candle model. (And the bottom of the wick should be similar to the candle wax)

I was surprised how rounded the tops of the real candle flames are. I think Bagginsbill's first version (bottom left) got the shape spot on.

The real candle flame with the red candle (top right) to me looks very similar to bagginsbill's matmatic shader (bottom right), with only the ellipsoid shape of the flame and length of the wick really being noticeably different. As I said before, that's down to my candle and flame model.

However, two of the other three screenshots of real flames show a distinct gradation of the flame from orange to yellow to white near the bottom of the luminous zone. But I haven't yet managed to work out the maths of the matmatic script to see how that could be added.

P.S. this video is fantastic - and rather odd until you realize that he's actually using Faraday's original words. It sounded like the Rockwell Retro Encabulator to me !

That Rockwell clip is WICKed hilarious!

One of those real candle flames that I posted looks to me like three ellipses one inside another (speaking two-dimensionally) so I tried to very simplistically reproduce it in GIMP. Here's what I did, with the real flame for comparison. What struck me most was that the GIMP thumbnails top left look surprisingly good approximations to the real flame.

I had a play with bagginsbill's matmatic-generated shader in Poser's material room to see if I could introduce a similar gradation of colour from the bottom to the tiop of the falme, specifically by plugging other nodes into the Inner_Color and Outer_Color inputs of the orange/yellow EdgeBlend node and altering the Saturation and Value of the HSV node connected to Alternate_Diffuse. 

No luck so far.

And no, I can't work out the maths to do it in the matmatic script itself.

P.S. I'm ignoring the blue zone here because I think that's already sorted.

Forgot to attach this annotated screenshot of the material room

(and apparently I also forgot to complete annotating it - it just indicates the bits I was playing with)

Just did an 'ellipsoid' morph for the flame...

Whoops !  I forgot that the flame shader uses the V coordinate of the UV mapping of the flame mesh, and that UV mapping is a bit arbitrary - a simple cylinder projection

I think the default flame mesh probably needs to be an ellipsoid to start with, positioned as per a real flame in relation to the tip of the wick.

Obviously the UV mapping of the flame and the use of the V variable in the shader must be correlated

Or how about a completely different approach - use the Y (vertical) component of the normal ?

Maybe the Normal-Y can be used, possibly in conjunction with an EdgeBlend , to control both colour and transparency ?

This approach might even work for oddly shaped flames, e.g. where the wick is long and bent over and the flame burns along it horizontally

Whimsically connecting nodes and twiddling values, not considering the physics or maths of a flame. But it looks as if it might lead somewhere.

(once again I'm not including the blue bit here - this is just an idea for the orange/yellow/white part)

This is very interesting, it looks like it's coming along.  This looks like it can be converted to Cycles without too much trouble once it is completely worked out.   I don't know your progress with Superfly rendering, in particular, using Cycles, but there might be problems with super bright ambient illumination as per your setup.  Mesh lighting can cause considerable render noise leading to long render times just to clear it up.  In my judgment, relying exclusively on ambient illumination as the primary source should be reconsidered, and use a low ambient flame with an inverse square point light emitting blackbody illumination.  IMO, that is the better way to use the candle flame in a scene. 

It's definitely coming along. :)

For my next trick I decided to concentrate solely on trying to duplicate the nested ellipsoids effect I did in GIMP a few posts back. I realized that trying to use colour would just confuse and distract me, so I stuck to black and white.

The first thing that struck me was that I could use the v (texture coordinate) node instead of just black/white as the Inner_Color/Outer_Color of an Edge_Blend node.

The second thing that struck me was that I could use Bias/Gain* in a Math_Function node to alter the output of the v node as required.

The third thing I realized was that high (>1) Attenuation values in the Edge_Blend node 

I was amazed - just eight nodes (nine if you count the PoserSurface) and it's looking remarkably good to me.

I just wanted to make sure that I don't lose that !

What I have here looks as if it might be good to plug into Transparency, and perhaps a ColorRamp driven by the v node for the actual colour ?

*I still don't really understand what these do

Not quite what I'm after, but promising

hborre posted at 4:26 PM Wed, 18 May 2022 - #4438797

This is very interesting, it looks like it's coming along.  This looks like it can be converted to Cycles without too much trouble once it is completely worked out.   I don't know your progress with Superfly rendering, in particular, using Cycles, but there might be problems with super bright ambient illumination as per your setup.  Mesh lighting can cause considerable render noise leading to long render times just to clear it up.  In my judgment, relying exclusively on ambient illumination as the primary source should be reconsidered, and use a low ambient flame with an inverse square point light emitting blackbody illumination.  IMO, that is the better way to use the candle flame in a scene. 

For the stuff after your post I've stuck to an Ambient_Value of 1. I'm using Ambient rather than Alternate_Diffuse (which is what bagginsbill used) because (a) I don't know the ins and outs of Alternate_Diffuse, and (b) Ambient seems the easiest way to ensure that I'm not getting any odd lighting interactions to confuse matters (I did set all the diffuse/specular stuff to black/zero too)

Yes, definitely, a colorramp node can recreate that gradation.  It's looking very good, very convincing. 

Connecting the existing Edge_Blend to the Input of the ColorRamp, instead of just the v node, looks even more promising...

Fantastic!

For comparison:

(I set the v node bias to 0.6 in bagginsbill's shader to get the height of the blue zone about right)

P.S.  I lost the original text I wrote due to a 502 bad gateway when I tried to post - this is my second attempt. Below is a much abbreviated version of what I originally wrote.

The glow and blue zone in bagginsbill's look spot on to me. But mine has the orange/yellow/white nested ellipsoids ! :P

And I see the black halo bagginsbill mentioned that his shader seemed to produce

I made another candle model (the table candle's flame is down in the melt pocket and so not visible from the side).  It has an unseen (does not cast shadows, not visible in camera) emitter mesh closely fitted inside the flame mesh.  The flame can be given modest ambient so that it doesn't white out, while the emitter has an ambient value of 256.  This is a Firefly IDL render;  note that it casts a reasonable amount of light (there is no point light used).  As @hborre noted, this takes much longer to get a clean render, and Firefly IDL is notorious for the splotchy lighting;  I would instead use a point light (scaled to fit the flame) for a single candle, but the method is great for an array of hundreds of lights where using Poser lights would be prohibitive.

BB's flame material, modified for dual root - the Superfly material adds the highlighted nodes which jack up the lightcasting output:

Flame prop properties:

Unseen flame emitter prop (for Firefly IDL use) properties:

This is where I *do* recommend use of mesh lighting:  lots of lamps in the elvish tree stairways (and the pixie dust trail):

...or odd complex shapes, such as the tubular neon of Xanadu:

I think I used 3DCheapskate's flame shader for this promo render a few months back.

Thanks seachnasaigh and ghostship2, the more people who join in the merrier !

Looking at the different rendered flames we've had posted side-by-side is interesting, so left to right: my original idea; bagginsbills first post; bagginsbill's matmatic-generated; bagginsbill's matmatic one again with a mod to allow for  my UV mapping and ellipsoid morph; my triple ellipsoid; ghostship2's promo from a few months ago; seachnasaigh's latest

Also I'll repost some of the screenshots of real candle flames for further comparison.

Of course, how a photo of a candle flame looks depends very much on camera settings. And what you see with your won't necessarily match a photo.

Plenty of room for further experimentation I think. :)

I made another candle model (the table candle's flame is down in the melt pocket and so not visible from the side).  It has an unseen (does not cast shadows, not visible in camera) emitter mesh closely fitted inside the flame mesh.  The flame can be given modest ambient so that it doesn't white out, while the emitter has an ambient value of 256.  This is a Firefly IDL render;  note that it casts a reasonable amount of light (there is no point light used).  As @hborre noted, this takes much longer to get a clean render, and Firefly IDL is notorious for the splotchy lighting;  I would instead use a point light (scaled to fit the flame) for a single candle, but the method is great for an array of hundreds of lights where using Poser lights would be prohibitive
...

I've been using a single point light for my candle for no other reason than that it's what I've got used to doing for a candle in Firefly. 

I'm still simply trying to get the flame itself to look right, or at least good enough for my purposes. I hadn't really thought about using it as a light emitter itself, or using any of the other alternatives to a point light. So it's good to see that you're way ahead of me on that one ! ;)

ghostship2 posted at 10:34 PM Thu, 19 May 2022 - #4438854

I think I used 3DCheapskate's flame shader for this promo render a few months back.

...

I'd be a bit surprised if that was my shader. If it is I'd guess that you'd made some changes to it. :)

Here's an interesting screenshot of a real candle flame, from the thumbnails of engineerguy's "The chemical history of a candle" videos on Youtube

There's a clearer picture at around 1.30 into lecture one

A couple of interesting visual points in that I think.

this is what I used. I had saved it to my presets months ago. The two sphere/flames light the scene

Thanks for posting that. It got me thinking...

One thing I've noticed is that I think we're all (except bagginsball) using a ColorRamp with blue at the bottom and yellow/orange/white for the other three.

But the last screenshot I posted of a real flame (engineerguy's green candle), and also the flame of the red candle rightmost of the four real flames posted a bit earlier don't seem to show any blending of the blue colour - at any point the flame is either orange/yellow/white or it's blue.

So what should the fourth colour of the (and I'll use my version of the ColorRamp here) white-yellow-orange-??? be ? Since the area with the fourth colour is mostly transparent you could say that it doesn't matter, but it clearly does - using blue just doesn't look right to me.

How about black ? And while we're at it the orange and yellow look too saturated to me so change those too (orange = 255, 180, 120, yellow = 255, 235, 150 or something like that). Also delete all the lights in the scene.

Just tidying up the layout of the nodes and adding the ellipsoid morph I used earlier to the original candle model...

The ellipsoid morph makes a big difference so I've zipped the morph target, Ellipsoid Flame.obj, and attached it to post 42 of the corresponding HiveWire3D topic along with very brief instructions.

Getting back to the blue zone of the flame. I'm now wondering how to add that to what I've got.

Just checking - it works with or without scene lights, and in both Firefly and Superfly.

It's doesn't look quite the same in Superfly, so some node parameters probably need Superfly tweaks

I don't think the PoserSurface works the well with Superfly.  I've seen variability between that node and the actual Cycle-based nodes, in this case, the transparency  settings do not have that many features accessible in Cycles.

Okay, I ran your ellipsoid flame shader through Cycle/PrincipledBsdf node combination and this is what I got;

It seems to confirm my suspicions about using the PoserSurface for Superfly rendering.  I'm going to run another render with full-blown Cycles to see what I get.

Straight Cycles with your flame shader.  I added the LightFalloff to simulate the Inverse Square effect and kept the emission strength low so that you can see the flames' gradient.  Otherwise, we will get a bright bloom.  

I turned off all the external lighting for the render.  Note the fireflies.

This is my best render with the settings as those above.  Flame light emission only using the PrincipledBsdf and an added hack to control the intensity value.  No Inverse Square, unfortunately, but keeping the emission intensity low will compensate for it.  Note, no fireflies.

I know sweet FA about Cycles, BSDF and all that jazz, so I'll take your word on those. :D

I'm focussed on Firefly (as per the topic title - although this is as good a place as any to get a Superfly candle flame shader working too).

I think getting that three Russian-doll-style ellipsoids effect working in Firefly is 95% of what I'm after. It did involve fine tuning of some parameters and I need to annotate the shader network screenshot before I inevitably forget. As I put the shader together I remember first plugging the output of the N node (default settings) directly into the PoserSurface AmbientColor and rendering my flame. Realizing I just needed the vertical component, adjusting accordingly, rerendering. Realizing I needed to add an offset, adding a Math_Functions Add and plugging that into PoserSurface AmbientColor, rendering again, adjusting, etc. The two Math Function Gains and the EdgeBlend Attenuation were trial and error.

Perhaps I should do Firefly/Superfly render comparisons with various node outputs plugged into PoserSurface AmbientColor to see if I can identify a single node that needs a Superfly-specific tweak ? Or maybe I should forget about Superfly and let those who are familiar with it take the reins ?

The big thing I notice from your last three renders is that two of them have an almost horizontal divide between the orange-yellow-white zones, and the other has the nested ellipsoids the wrong way round - joined at the top, white smallest, inside yellow, inside orange largest.

Regarding adding the blue zone to my last shader I tried a few ideas but my only even vaguely successful result was this

The blue was a SimpleColor node because I was planning to combine this with the previous flame shader. However, looking at the pictures of real flames again I thought "the blue is almost a completely separate thing"...

So I just tried duplicating the flame ellipsoid mesh, making it 5% larger, and applying the blue zone shader just to that.

Firefly left, Superfly right, with and without lights. Flame shader same as before.

Once again not so good in Superfly, but I'm delighted by the Firefly results !

I also had a third ellipsoid, 5% smaller than the first, to use as an invisible-in-render light emitter... but you can't do that with props. I mean make part of the prop invisible-in-render, make another part not-cast-shadows. I think the flame needs to be nested props or perhaps a figure to do that ?

Also I think that creating just a candle-flame prop/figure, i.e. without the wick/candle, is a good idea - that way I can use it on all those candles in my runtime. Which was actually the reason this topic reignited after a two year hiatus !

3dcheapskate posted at 12:07 AM Tue, 24 May 2022 - #4439021

...

Perhaps I should do Firefly/Superfly render comparisons with various node outputs plugged into PoserSurface AmbientColor to see if I can identify a single node that needs a Superfly-specific tweak ? Or maybe I should forget about Superfly and let those who are familiar with it take the reins ?

...

Below screenshot from render comparison in Poser - one side FF, the other SF

I can't seem to get Superfly to render the flame like Firefly changing just the PoserSurface transparency stuff, but maybe a Supefly-specific EdgeBlend driving it would work ? But I'm not going to go down that path - I'm giving up on getting this flame shader to work in Superfly.

So over to all you Superfly users :)

If anybody has alternative Firefly shaders please do continue posting. What I've got now* is, I think, good enough for me. But maybe not for everybody.

*  I'll package it up and release it as a freebie - no ETA. Sitemail me a reminder if I forget !

I've created a brief (2 seconds) video of an animated candle flame using a modified version of my candle prop.

Have a look at it on Youtube:

Poser Firefly candle flame test - YouTube

And a slightly longer 5 second video - just a pointlite that I manually animated to match the movement of the flame

Another very short Poser Firefly candle flame animation - YouTube

You shader masters have my awe-filled respect. I'm not competent to use the math nodes or most of the other functions you power-users use so nonchalantly.  When I want to create a shader that replicates the reflective safety stripes on safety vests and such, I just throw up my hands and babble.  And Superfly is utterly beyond me.

Well done, all!

Needed candles for a scene I was working on so I decided to try the one here. There was a little adaption needed for superfly. The only light is from the candle and the light emitter which I did put high.

And a slightly longer 5 second video - just a pointlite that I manually animated to match the movement of the flame

Another very short Poser Firefly candle flame animation - YouTube

Wow, that looks pretty good!

Converted everything in this scene to Superfly shaders and added Blackbody emission shaders to the point lights for each candle.  For the tealight, I used an open-end pipe primitive, shaped to fit around the candle and given a brushed aluminum procedural shader texture.  The faerie is Miki 4.

Somehow I stopped getting notifications. It's good to see that people are playing with this in Superfly too.

While messing around with an extra, separate EdgeBlend to drive transparency for Superfly I tried using values of PoserSurface transparency higher than 1.0, and since I tried using different values for Transparency and Transparency_Edge I also set Transparency_Falloff non-zero. What surprised me was that when I set both Transparency and Transparency_Edge back to 1.0, Transparency_Falloff still appeared to have a significant effect in Superfly. So I played around a bit more - I ended up with two extra nodes and a Superfly render that more or less matches my Firefly render.

Here's the Superfly version, changes from Firefly version marked in red:

And here's the Firefly one that's in the freebie as a reminder, and for comparison: