11-22-2023, 11:05 AM
Hi again,
I see three scenarios to implement your editor:
A - Have your editor be just an UI that controls Curvy Generators (CGs for short) that do the actual work.
B - Do not use CGs, but use the relevant methods/code from the CG code. This implies that you will have to convert data from and to data formats used by the CG, such as CGSpot and SubArray<> (the later which exists to make CGs performant).
C- Do not use CGs, nor use its methods, but extract specific parts of its code, and modify it to be compatible with your data format.
I recommand scenario A, but you said you prefer to not follow this path for performance and simplicity reasons. My question is: Have you witnessed any significant performance issue? CG is not perfect, and sure has room for optimization, but a lot of work was done to make it performant, and supports frequent updates. If you witnessed any performance issue that makes you exclude scenario A, please let me know, so I can try to fix it.
Scenarios B gives you more freedom, but need way more work due to the data format conversion. By following this path, I feel like you will be swimming against the current, by trying to reproduce yourself what the CG does already.
Scenario C needs that you dig deep in the code, and understand it so that you know what code exactly you need to extract.
I see three scenarios to implement your editor:
A - Have your editor be just an UI that controls Curvy Generators (CGs for short) that do the actual work.
B - Do not use CGs, but use the relevant methods/code from the CG code. This implies that you will have to convert data from and to data formats used by the CG, such as CGSpot and SubArray<> (the later which exists to make CGs performant).
C- Do not use CGs, nor use its methods, but extract specific parts of its code, and modify it to be compatible with your data format.
I recommand scenario A, but you said you prefer to not follow this path for performance and simplicity reasons. My question is: Have you witnessed any significant performance issue? CG is not perfect, and sure has room for optimization, but a lot of work was done to make it performant, and supports frequent updates. If you witnessed any performance issue that makes you exclude scenario A, please let me know, so I can try to fix it.
Scenarios B gives you more freedom, but need way more work due to the data format conversion. By following this path, I feel like you will be swimming against the current, by trying to reproduce yourself what the CG does already.
Scenario C needs that you dig deep in the code, and understand it so that you know what code exactly you need to extract.
Please consider leaving a review for Curvy. This will help a lot keeping Curvy relevant in the eyes of the Asset Store algorithm.
