Feature Request - Star Shaped :ights

lrhorer

New member
Feature Request - Star Shaped Lights

I tried to set up an account on the bug tracker, but it won't let me log in. It would be nice to be able to create light fixtures that are not just a circle. For example, I have some star lights. They are a single pixel, but it would be nice to be able to represent them as stars, not just a blob of light. Right now, in order to crate a star, it must be several pixels.
 
Last edited:
PM me the username and email you used to sign up on the bug tracker and i'll see what's going on.

You can use the star smart object and just link all the nodes to the same element, That'll give you an unfilled star. Or you could create a custom prop to do the same but can look however you like.
 
No, that is backwards. I am not asking for multiple nodes mapped to a shape. That is easy enough. I am asking for a different shape for each node (i.e. star shaped lights, not a star ornament). Right now every node is round, regardless of the shape of the ornament.
 
I get what you're saying. Just offering a workaround. After all, any shape on screen is just a series of dots (screen pixels) next to each other. So you could certainly use any of the shapes we already have and just make them dense enough that it looks like the shape you want it to be. In other words, one vixen element, many preview dots to represent it.
Here's an example. I used the star object with a light count of 120 and all of those lights are linked to one single element.
Star.png
 
No, no, no. The light count for each object (in this case) is 1. It is never anything but 1. One light, one element, with the element shaped like a star (or a square, or a triangle, or whatever). A string of 120 elements would consist of 120 stars, not 120 elements per star. Take a look here: https://www.aliexpress.com/item/977989040.html?spm=a2g0o.store_pc_allProduct.8148356.5.7b1bfa3192Zsce

Each of those stars is a single RGB pixel.


I think you are missing what Jon i suggesting. In his example, there is only one element or node in the Vixen tree. The preview does not dictate how many nodes/elements there are are, it is just a view of it. Imagine a string of ac lights, that has 25 lights on it, but they all light when the string is on and are a single element or node in Vixen. So if you map that one element in Vixen to the star with 25 lights on it, all 25 will light up in the preview when the one element node (your single RGB pixel) in the tree has an effect on it. The nodes in the element tree define how many actual lights there are, the preview is just a view of how it might look. Set the star to have standard lights instead of Pixel and it will automatically map all of them to the one element you associate it with.

We are not discounting your request for a feature to make it be a filled single shape, and that may be something we do that provides for the user to provide an image or SVG of the shape so we don't go down the trap of having to code for every specific shape a user might need. The above is an option to give you something that looks more like a star, but still behaves like the big single dot you are using now.

Hope that helps clarify.
Jeff
 
I think you are missing what Jon i suggesting. In his example, there is only one element or node in the Vixen tree. The preview does not dictate how many nodes/elements there are are, it is just a view of it. Imagine a string of ac lights, that has 25 lights on it, but they all light when the string is on and are a single element or node in Vixen.

So for this discussion, you are defining node and element to be synonymous, correct?

So if you map that one element in Vixen to the star with 25 lights on it, all 25 will light up in the preview when the one element node (your single RGB pixel) in the tree has an effect on it. The nodes in the element tree define how many actual lights there are

OK, you lost me. Instead of a string of AC lights, let's talk about a string of 25 RGB lights with a single set of 3 addresses / patch points, which we will call a node, and is mapped to a single element in the Display Setup. It has a variable physical shape, but only 1 logical ID in Vixen.

the preview is just a view of how it might look.

Surely. Let's call that an ornament.

Set the star to have standard lights instead of Pixel and it will automatically map all of them to the one element you associate it with.

There you sort of lost me, again. A standard light only has one address / patch point, correct? That is only 1/3 of an element. Let's keep the discussion to pixel nodes with three patch points, if you don't mind. It will save confusion on my part.

Right now, as I understand it, any ornament has only 1 possible shape in the preview: a circle of variable size. This is the case whether the ornament is a dumb light, a dimmable light, or a pixel. Is that understanding not correct? If so, I don't see how to change it.

We are not discounting your request for a feature to make it be a filled single shape, and that may be something we do that provides for the user to provide an image or SVG of the shape so we don't go down the trap of having to code for every specific shape a user might need. The above is an option to give you something that looks more like a star, but still behaves like the big single dot you are using now.

Yes, that sounds like the notion inherent in my request precisely, and thank you, by the way. It is definitely not a huge deal in the overall scheme of things, but it would help the preview look more precisely like the actual physical display if each ornament were the same geometry as the physical shape of the real ornament. Of course, most ornaments are more or less just round(ish) dots, but some are not.

Hope that helps clarify.

Well, I think we can get there, let me put it that way.
 
Oh, hey! I understand, now. I created a star object with 40 lights in the preview, but configured it as a standard string. I assigned a single pixel object to the resultant ornament. I was confusing the fact the object was a pixel with the fact the ornament is a single light string. The single string ornament can still have a 3 element pixel assigned to it.

The disadvantage, here, is one must crate an individual object for each ornament. This is rather slow and tedious. It would definitely be nicer to be able to create, for example, a string of 20 star-shaped ornaments and be able to assign an entire string of elements to the string of ornaments in one operation. Creating and moving 20 individual objects on the preview and assigning 20 different elements to 20 different ornaments took quite a while.
 
Last edited:
Ok, good. The concept we were talking about is sinking in. The output patching to the 3 channels for RGB is distinctly different than linking the preview up. They are independent and thus affords some flexibility.

I was going to suggest an easier workflow to add multiples, but when I walked through it myself I found a bug that needs to be fixed. There are ways to add multiples fairly quick once you select the shape, you can just elect the element to link it to and add them in succession. Assuming a string of dumb nodes that look like stars, you want all the stars to be linked to the same element in the tree because they will always do the same thing, So you would just keep selecting that element and adding another star until you have all of them. They will default to standard and have 40 points of light in the star. If 40 works then you are good to go. You can use the other alignment tools to line the up, and even set them all to be the same size in reference to one of them with the match properties. That can help add them quicker. If you change the light count in them, then there is a bug that you have to relink them afterwards to link the extra ones. I'll get a ticket in to fix that bug.
 
So I have the work-around, but I think the request is still valid, agreed? Now that I have the tracker working, so you want me to issue a feature request?
 
Yes you can create a feature request. It will likely be low priority, but having a ticket will give us the ability to keep track of the request and it's popularity.
 
I would agree. The better option here would be a feature that more broadly let the user provide some sort of SVG or the like for the shape to link it to and then it would have broader appeal.
 
Back
Top