Results 1 to 6 of 6

Thread: UNsynced 'navigation lights' ? / blinking lights, not in unison / centrally controlle

  1. #1
    Axes grinder- Dongle #99
    Join Date
    Jul 2003
    Location
    Seattle
    Posts
    14,734

    Question UNsynced 'navigation lights' ? / blinking lights, not in unison / centrally controlle

    Got a structure, putting on navigation/warning lights.

    I'd prefer they not blink all simultaneously, AND just for drill, I'd prefer to have one central location in the scene from which to adjust their speed and cyclic duty. (That is: I could just brute force it by hand, but that's not very professional is it?)

    All approaches welcome, but I'd be very interested in a nodal solution.

    I plan to use simple point lights for these pups.

    Thanks!

    (PS: just for fun I decided to try using Luxigons....we shall see...)
    They only call it 'class warfare' when we fight back.
    Praise to Buddha! #resist
    Chard's Credo-"Documentation is PART of the Interface"
    Film the cops. Always FILM THE COPS. Use this app.

  2. #2
    Registered User
    Join Date
    Jan 2005
    Location
    Colorado Springs
    Posts
    1,795
    This is one of those "Good-News-Bad-News" kind of responses.

    The Good News is that yes, it's possible to do a nodal solution and trigger the running lights on a randomly determined interval. The Bad News is that converting Luxigons has to be done very carefully or the node network doesn't receive the correct Item ID's for generating the per-light random interval.

    For running lights I've found that Lens Flare is a better option than Light Intensity, so the attached scenes primarily depend on Lens Flare for the running light effect.

    Attached are three scenes: the RandomLensFlare_Base scene is one light with the node network. The RandomLensFlare_FullSphere_Base scene loads the 4-layer sphere (one layer of geometry, one layer each of Reddish, Yellowish and White luxigons) and clones the Light into the Reddish, Yellowish and White lights and copies the node network into the Light Intensity, but doesn't convert the Luxigons. The third, final scene has converted all Luxigons in a four-phase method to work around the Luxigon conversion problem described below.

    These sample scenes use TrueArt's Render Info node to get the current frame, and DPKit's Item Info to get each "cloned" Light's unique Item ID.

    RandomLensFlare_FullSphere_ConvertedAllLuxigons.mov

    Click image for larger version. 

Name:	001_TexturedLensFlareIntensity.jpg 
Views:	75 
Size:	1.23 MB 
ID:	138340 Click image for larger version. 

Name:	002_NodeSetup.jpg 
Views:	79 
Size:	500.0 KB 
ID:	138341

    The issue with converting Luxigons is that the first time you do it in a scene, it appears to set up some internal state which causes later Luxigon conversion(s) not to propogate the node network correctly. It seems that the DPKit Item Info node isn't able to produce the unique Item ID (or other per-item information like World Position) required to generate the random interval for each light's blinking. Indeed, you have to QUIT LAYOUT for it to work correctly again...simply clearing the scene isn't sufficient. For the 2nd or later Luxigon conversions, all the lights will generate the same "random" interval and blink together.

    So, the third attached scene, RandomLensFlare_FullSphere_ConvertedAllLuxigons, was created in four phases: Load the Base scene, convert the White Luxigons, save the scene as ...ConvertedWhiteLuxigons, exit Layout, get into Layout again, convert the Yellow Luxigons, save scene as ...ConvertedYellowLuxigons, exit Layout, run Layout again, convert the Red Luxigons, save scene. Finally, open ...ConvertedWhiteLuxigons, use Load Items from Scene to bring in the appropriate Lights from ...ConvertedYellowLuxigons and ...ConvertedRedLuxigons and save as ...ConvertedAllLuxigons. Note that you can Select None and then double-clicking on the Lights section in Load Items from Scene selects all Lights, and you can deselect the singleton lights RedLight(1), YellowLight(1) and WhiteLight(1).

    Anyway, other than the royal hassle of Convert Luxigons not working more than once per Layout session, it seems to work OK. The node network has several "parameter" adjustments:

    • FrameShift - this offsets the initial frame for the blinking, otherwise the lights ALL flash at frame zero (because of the Mod(1) and Logic(1) nodes) and then separate more and more as the animation progresses.
    • Blink Rate Minimum and Range - these specify the minimum number of frames that a light will blink, and the Range is now long the maximum blink interval will be. The smaller the Range, the more likely lights will blink simultaneously. I only have the Range set to 20 in the sample scene, so often you'll see lights blinking together, but I think that's OK.
    • Intensity Minimum and Maximum - these specify the lens flare minimum and maximum. The attached scene has the minimum at 0.02 (2%) and maximum at 0.05 (5%). Be careful with too-high intensities, or it looks pretty fakey and can certainly overwhelm a VPR preview.


    Of course, rather than having Constant Scalar nodes in the network, you could use the Item Info node to get the Position, Rotation or Scale of one or more controller Nulls.

    Have fun!
    mTp
    Attached Files Attached Files
    Last edited by MonroePoteet; 10-18-2017 at 07:04 PM. Reason: Add external node dependencies

  3. #3
    Axes grinder- Dongle #99
    Join Date
    Jul 2003
    Location
    Seattle
    Posts
    14,734
    Holy Cannoli, Monroe, that's a lot of work to go thru (for a fellow LWer)!!! Thank you very much!

    (I had already sort of written off Luxigons: yes, I am a quitter.)
    They only call it 'class warfare' when we fight back.
    Praise to Buddha! #resist
    Chard's Credo-"Documentation is PART of the Interface"
    Film the cops. Always FILM THE COPS. Use this app.

  4. #4
    Registered User
    Join Date
    Jan 2005
    Location
    Colorado Springs
    Posts
    1,795
    You're welcome, but the only real work was the hassle with the Luxigon conversion. I'd done a similar nodal setup previously, and thankfully, once I set up the node network, the first Convert Luxigons worked exactly as I expected, and then quit working when I modified the node network. It took me a while to realize it wasn't a bug or bugs in my node network, but the problem with subsequent Convert Luxigons in the same Layout session.

    If either the native Instancer or DPInstancer would instance Lights it would have been done MUCH faster, using the Instance ID for the random seed and avoiding the Luxigon hassle.

    mTp

  5. #5
    Registered User
    Join Date
    Jan 2005
    Location
    Colorado Springs
    Posts
    1,795
    Here's an updated sample scene which has Sliders to control the various "beacon" parameters (via the Beacon Control null), and randomizes the color as well. What I've been doing is using the Array function in Layout to clone the Light into a 10x10 array to see the effect of the Sliders.

    Click image for larger version. 

Name:	LensFlare_NodeSetup.jpg 
Views:	52 
Size:	1.32 MB 
ID:	138353 Click image for larger version. 

Name:	RandomLightColor_NodeSetup.jpg 
Views:	40 
Size:	876.2 KB 
ID:	138354

    Cloning the Light with Array has the same Item Info propopation problem that Convert Luxigons does: sometimes the 2nd or more clone causes all the Lights to have the same parameters causing them to blink together. Again, quitting and restarting Layout seems to be required to reset whatever internal state is set up.

    To use the Sliders, you have to select the Beacon Control null and press CTRL-D to enable the sliders. They're only visible in VPR if you enable to OpenGL Overlay, and then you get a Light icon on top of the lens flare, which obscures the effect. The sliders can be changed while the timeline is playing but it produces an Envelope with keyframes on the timeline. What I tended to do is always go to Frame 0 to change the sliders in Textured Wireframe mode, switch to VPR to run the timeline and see the effect, repeat.

    Enjoy!
    mTp
    Attached Files Attached Files
    Last edited by MonroePoteet; 10-21-2017 at 09:11 PM. Reason: typo

  6. #6
    Registered User
    Join Date
    Jan 2005
    Location
    Colorado Springs
    Posts
    1,795
    P.S. An important note: the random Light Color node network is duplicated in the R, G and B channels, since there doesn't seem to be any nodal method to affect the R,G,B channels in a single node network. If you want to change the Gradient which determines the available Light colors, you have to modify the Gradient in each of the R, G and B channels.

    mTp

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •