- User Since
- Nov 17 2010, 3:54 AM (426 w, 1 d)
Dec 11 2017
Sure. I don't think I can do this. No such action available.
commited in e6b81de7e1765aa62c56c46a724d67751f321111
Dec 8 2017
sorry I somehow was caught in Java-thinking and didn't expect more than one class in a file..
I don't know exactly how python behaves if you have a getter property and an attribute with the same name. But I assume the getter property will always be called when you want to access that attribute/property. So yes, setting .is_closed might not fail, but I still think it's better to straightly modify flags, since I *assume* we're always calling the property, when we want to know about the .is_closed property.
Thanks for adding elevation support. I don't see any problems with this. Please share the DXF file if possible. How big is it when you zip it? You could share it with http://pasteall.org/blend/ if it doesn't exceed 30MB.
Oct 23 2017
Also, you can use "center geometry to scene" option and leave away "merge objects" option in your case.
added an if statement to make sure the width property of dxf entities can be accessed as a 2dim array.
[can't remember how to link commits... ]
Jun 1 2017
If in do.py you move line 1423 after 1426 it helps with the rotation, but I have no clue at the moment how that affects other dxf files.
solved with d2ed52f2134e
(updated dxfgrabber library)
May 12 2017
Here the importer relies on the dxfgrabber library. I have been in contact with its developer a lot when developing the dxf importer. He says, there is no open documentation on DXF solids, since AutoDesk just inserts solids in binary format into the dxf. He was only able to export the solids to sat files. So the behaviour you experience is not a bug "but a feature". We could also just ignore the solids completely, as it was the case with the former dxf importer. At the time when developing the dxf importer there was no python library to read sat files. Therefore, you might rephrase your problem as a feature request. But I am not able to help you with this right now - even if you find a python library for sat files.
added try/except clause; commit cb5b13309073ae7593bc537e8c14ab0bd4f15470
Do you really think this is a simple shape? It's a 3D shape with 210 faces. Or if you really do think, this importer cannot even handle the most simple shapes then start look for the error yourself and adjust the script. The fix I now added, could have been added by someone with at most one hour of intro to python. Just leave out the emotional judging. And don't forget to activate the option that centers your geometry to the middle of the scene. Even AutoDesks online dxf viewer struggles with your geometry when orbiting around it, because it's sooo far away from 0,0.
Mar 3 2017
Could reproduce your error with an old 2.72 installation. Looks like you have an old addon in your addons folder. The import works with 2.78. I even checked it on windows for you.
Feb 1 2017
first, install pyproj as discussed with you on blenderartists already.
Oct 11 2016
commit 1b58a90cd418 should solve your issues with bug 3.dxf.
Oct 7 2016
Your file has a spline with two point having the same location. The importer should actually handle this; for some reason it didn't.
Aug 20 2016
ok. forgot to push. pushed now.
Aug 18 2016
and just to avoid an extra round of posts here:
As you can read from the error message ImportError: No module named 'io_import_dxf.dxfgrabber.dxfentities' your error does not have to anything with your files but with my second last erroneous commit. I Added the two missing files last night. So you might just need to update your build and try again.
I tested it with the newest version. "ä" does not seem to be a problem (anymore?). But I needed to fix a problem with an extrusion value.
Aug 17 2016
ok. but if I replace all inf.0 with inf and turn off all merging options (no clue yet what is wrong there) I can import your file in Blender. Did you attach the correct file?
Aug 16 2016
I looked at it. Forwarded the issue to the author of the dxfgrabber library: https://bitbucket.org/mozman/dxfgrabber/issues/13/inf0-values-not-parsed-properly
Jun 28 2016
tracker url in bl_info has been updated in an earlier commit
ok... next time maybe somebody not struggling with git wants to do it...
the bugfix by domlysz seems to be valid according to the pyproj documentation. I don't have test environment at hand atm. I expect the amount of users using pyproj to be very low anyway.
Mar 22 2016
Aug 29 2015
Well, that's what you get if you start arguing that a major useability improvement might not be necessary...
@Bastien: I agree with Donatas. Ask architects why they prefer modeling in Rhino (or ArchiCAD or SketchUp up to some point): because it's easier (= more intuitive (= has better snap tools)). So at the moment the only reason why this patch would not be used so much, is because architects don't use Blender so much. It's exactly patches like this making Blender better for architects. So arguing against it, because it would not be used, is a bit unfair. I think it's an amazing proposal and a great work by Justas and everybody who started working on it. It's a VERY(!!) helpful step towards more architects using Blender.
Example: With this feature I don't need to create transform axes anymore. You know how many times I tried to teach that to my students? When I did, they always asked: uhm, why do we have to learn Blender? Even some of those who were not as skeptical abandoned Blender after a while. Probably because they did not remember the workarounds anymore (or thought it takes too long to create transform axes).
So, if this patch makes messy code even messier (didn't look at it) then the whole code probably needs to be redesigned anyway? I can understand your concerns about the code. I also don't like code to be a huge mess. But this feature should definitely go into master as soon as possible to my opinion.
Oct 21 2014
Thank you marek for noticing me of this error. It should be solved now. The commit is here: http://git.blender.org/gitweb/gitweb.cgi/blender-addons.git/commit/570b7d94b3b2414e376d9eddd4f3a2df1e4dbb88
Closed by commit rBA570b7d94b3b2.
Commited as rBA68e4b7e6bf9d
Oct 16 2014
As for the numeric import: the inputs are treated as strings, since in Blender numeric inputs tend to end up being 0.99999999 instead of 1.0. If I treat everything as strings and convert the strings in python "1.0" remains "1.0". I can check if I can replace comas with points in the strings. But do you really need it? BTW if I type 0,7 in any other numeric Blender field, I get 7.0 instead of 0.7 (tested it with location.z). So I don't think I need to do something about it.
Concerning the arcs: I will look at it and try to fix it in the next days.
Oct 15 2014
Since your error messages are thrown by the dxfgrabber library I was in contact with its author. Short answer: DXF versions before DXF12 (AC1009) are not supported. I replaced AC1006 with AC1009 in your file and it works. BUT: we still don't know how this might behave. Since there is no complete documentation of any DXF version older than AC1009, those old versions are not supported by dxfgrabber. Any version other than DXF12 therefore gets treated as DXF13, which causes your errors.
I propose you change AC1006 to AC1009 and do some further tests. If everything works fine, we are happy. Otherwise I would propose to make your files conform with DXF12.
Oct 14 2014
Yes. I will have a look at it.
Sep 30 2014
Sep 29 2014
Jul 31 2014
in curve.c --> BKE_curve_bevelList_make --> STEP2 I took out the redundant calculation of bevp->offset. it is being calculated already in STEP 1.
Jul 30 2014
Thank you for the corrections. The issue with the first segment disappearing was an small mistake of mine: move "bevp++;" from line 1398 to line 1393 and it should work out fine.
When I replace MEM_callocN with MEMmallocN I get a strange flickering of the beveled curve when sliding the factor sliders. I propose to leave it with MEM_callocN. There must be a reason why "bl" is initialized with MEM_callocN.
Jul 28 2014
I've been working on a fix. Had some other work to do first. Struggling with Phabricator again, therefore only a diff:
Jul 19 2014
Yes I will have a look at it.
EDIT: What about calculating the length of curves directly in BKE_curve_bevelList_make() in STEP 2 ? I don't see any other reliable possibility to find out whether some bevpoints where omitted for optimization reasons. Would you agree on this?
Jun 3 2014
May 26 2014
Sorry for urging you to test so much. I am new to C but I will get into the XCode Instruments to deliver a better performance in memory testing next time!
zero check for cu->resolu_ren is not necessary anymore since I get the segcount from nu. It also caused the spline to vanish completely. That might has to do with the array errors you discovered.
Cyclic splines: While I had the idea for this feature thinking about open curves, I think it makes sense for cyclic curves too. It basically always makes sense when you want to animate bevstart/end linearly but having segments not equal in length.
May 25 2014
updating the diff
May 18 2014
inspired by "curve_to_displist()" I could fix the vector bezier handles issue.
Additionally I fixed a problem that became only visible with poly splines: swapping start and end factors occurred sometimes in the wrong place because last- and firstblend were not checked in the if-statement on line 1522.
May 16 2014
I think I could fix it: