Any further planned progress on MAKE2D ?
I find the current state of improvement SIGNIFICANT, but still have some things I’d like to see. I went to what I THOUGHT was a make2d thread, but it wasn’t clear where the latest posts were in the list, and it looked like it’d been closed ?
I’m finding LOTS in -6 still feels “WIP”-ish, but I generally find it to run more smoothly overall than -5.
Thanks -
-C.
I cfee,
I think it’s best to report all you findings with examples and files. That will be the best way to help improve make2D. Also post any suggestions you have. I’m sure @GregArden will collect them and put them on the backlog
-Willem
So what you’re TRYING to say is that I’m right - the other make2d thread IS closed ? Ok, I’ll post comments as replies to my thread, going forward.
Thanks -
C.
If you want to report different issues with the same command, start NEW threads.
There’s a reason why overcrowded threads get closed…
Thanks for the pointer !
To start with, I find lots of curves on top of curves still, and am expecting I’m just not aware of a setting that really ought to be the default ? Could this be connected with some very tiny curves that shouldn’t be there but are still getting through, or some curves behind what OUGHT to be hiding surfaces still getting through ?
Thanks -
C.
If you post a file, someone can do an analysis of what’s happening… Otherwise it’s just a discussion around a lot of “theoreticals”.
Or someone familiar can suggest settings, if they’ve encountered something similar …
Post a file…
So- YOU aren’t seeing tiny curves or faces that ought to hide curves behind them letting them through ?YOU aren’t experiencing ANY curves on top of curves ? Is this with default settings ? I’ve already turned off silhouettes edges as redundant.
Sigh… Post a file…
No, YOU determine whether REPORTED issues are CONSISTENT with YOUR EXPERIENCE and POST BACK. Sigh.
If the reported issues were intended, the answer would simply be: “That’s how it should be.”
If they were unintended and commonly known, (read as “CONSISTENT with YOUR EXPERIENCE”), the anwer would probably be: “We’re aware of this bug.”
If the reported issues were neither intended, nor commonly known, then you should expect a request for the specific file that demonstrates the unexpected results. Because most likely, the common usage does not show your issue. Maybe you could provide a simple description of your process like “make a box, hit Make2d, see a million shattered lines on top of each other”.
… or better yet, just post a file!
… OR you could go ahead and admit that three’s still a problem - the VERY SAME problem that has been reported all along, that many folks are dealing with this and multiple reports are are continuing to be posted, and that the threads on the topic are valid. The ONLY POSSIBLE need for a “file” is to debug an issue in a particular implementation, which is NOT appropriate for this situation. So - oh what’s the use. Apparently YOU aren’t experiencing ANYTHING the rest of us are dealing with. That’s fine. All the best - C.
The only way to fix issues is to have repeatable examples of what isn’t performing well. While the problem may seem glaringly obvious to you, we all use Rhino differently, and what you find objectionable others might not, or might not notice, or it might behave differently under different circumstances so they are simply not encountering it in the same manner that you are.
It can almost be guaranteed there are improvements that could be made to Make2D, and I don’t think anyone is trying to argue that the tool is perfect and finished. The issue is a lot of things could be contributing to the poor output you are seeing, and it is hard to say what could improve the situation without knowing more. This is why the request for a file, as it is the easiest way for others to help. With a file to look at, that gives an example of what isn’t working well. Not only can the result you are seeing be examined to further understand the issue, but suggestions might be able to be made which could improve the result, or provide an actionable example for developers to improve the tool.
Sam
SamPage
"While the problem may seem glaringly obvious to you, we all use Rhino differently, … "
So- others are using THEIR RHINO and NOT seeing such problems ? I JUST shared my experience with all of this on ANOTHER thread on this EXACT TOPIC posted by another user. SERIOUSLY, This level of dismissiveness brings it all to a new level ;=) (!) Well_DONE ! I’m genuinely impressed !
Chuck in Texas
I’m not sure why you are so combative about this. Many here said they would be willing to take a look and offer help, and the best way to do that is having a file that demonstrates the problem.
With out the file, the best that can be said is be sure your objects are close to the origin, try reducing tolerance, try it in chunks. If you want better than that, post a file of what you are seeing.
Sam
Sam-
Your response ONLY works if the problem exists ONLY in a single model and is NOT “general” in scope. SINCE the problem is GENERAL in scope, the behavior exists as implemented, and is NOT a bug-fix type of problem.
Best bet ? Review the comments, look at coding, look at results and decide whether there is going to be an improvement in the condition or if instead we discover at RH-7 (2, 3 or more YEARS in the future) we’re STILL bringing up the same set of problems with Make2D or not.
As for combative, NOT “combative”, declarative. There’s a difference. No room for combative, no substitute for declarative.
Thanks for your efforts, but if this is as far forward as we’re looking for the foreseeable future, just say so. If however you’re working on it, as you continue to progress - take a look at results, match them to comments, all intended to be constructive, and keep working forward. Choice is yours, we’re all here for the long-run.
Thanks -
-C.