For ever, I've been thinking there should be a way to let devs know which RFE's are worth more than others. Has this been thought about ? If not, what about the system they've implemented at orbolt ? How is this managed right now ? How do developers know when two different users are asking for the same enhancement. How do users know if what they're craving about has been asked already, and therefor instead of filing a new RFE they should push an existing one ?

lol enjoy your Maya-hotkeys-by-default…

No, please never go the ‘voting’ way. After ad killed Softimage I tested Maya for months before trying out Houdini.
Every single RFE I submitted to ad eventually dropped of the list.

If more people submit RFE's for a single feature, the dev's will know about it…one of the many things I love about SideFX.

cpb
lol enjoy your Maya-hotkeys-by-default…

?????????????????????

Could you elaborate ????

Werner Ziemerink
No, please never go the ‘voting’ way. After ad killed Softimage I tested Maya for months before trying out Houdini.
Every single RFE I submitted to ad eventually dropped of the list.

Could you clarify ?

Werner Ziemerink
If more people submit RFE's for a single feature, the dev's will know about it…one of the many things I love about SideFX.

Please read and try to understand what I'm asking, if I may be so bold.

Thanks.

-1

We have a database of bugs and RFEs. If the same (or very similar) RFE comes in, it is marked “duplicate” and the requester is added to the list of interested parties for the existing RFE. Over time, that RFE may get quite a few interested parties attached to it and becomes a good indication of interest, or at least an area that's deficient in the software. So essentially, you are “voting” with your RFE when you submit one.

When it comes to addressing those RFEs, some RFEs are implemented directly, other times it is taken as “something is lacking in this area, how can this be addressed?”, and other times it just doesn't fit in it all with the direction of the software. All of that is weighed against limited developer time, the focus areas for the current version, its overall impact, and other RFEs.

twod
We have a database of bugs and RFEs. If the same (or very similar) RFE comes in, it is marked “duplicate” and the requester is added to the list of interested parties for the existing RFE. Over time, that RFE may get quite a few interested parties attached to it and becomes a good indication of interest, or at least an area that's deficient in the software. So essentially, you are “voting” with your RFE when you submit one.

When it comes to addressing those RFEs, some RFEs are implemented directly, other times it is taken as “something is lacking in this area, how can this be addressed?”, and other times it just doesn't fit in it all with the direction of the software. All of that is weighed against limited developer time, the focus areas for the current version, its overall impact, and other RFEs.

Oh that's great to know! Thanks a lot

I guess the only way to get an RFE moved up on the list is to tell people about it, so they submit similar RFE's.

Ahem: Please support my RFE for accessing SOP data in COPS with a true COP VEX node.

Daryl Dunlap
I guess the only way to get an RFE moved up on the list is to tell people about it, so they submit similar RFE's.

Ahem: Please support my RFE for accessing SOP data in COPS with a true COP VEX node.

I've done this already. Can you give me a clear example ? I'll toss a hip file if I can.

I mean, you can already access sop data in cops in a vopcop, so if you need help in achieving something I could post a hip file.

A-OC
I mean, you can already access sop data in cops in a vopcop, so if you need help in achieving something I could post a hip file.

Say I have a 1 polygon plane with UVs and a COP mapped image on it, and I also have some Points. In COPs I'd like to read in the Points positions and color the COP image based on their relative position to the 1 Polygon Plane, so that the closer the point is to the plane, the stronger its color effect on the COP image.

This way, I have an effect that is not dependent on the resolution of the target mesh object.

https://www.sidefx.com/forum/topic/51437/?page=1#post-231245 [www.sidefx.com]