| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Spliting edges for this purpose is doing more harm than good,
additionally not all DCCs import PLY normals anyway, including Blender.
|
|
|
|
New geometry traversal code, use bmesh data instead of mesh,
simpler logic.
This also fixes split faces when exporting normals and vertex colors.
Exporting UVs still results in split faces, since UVs are stored in
vertex data (not sure if PLY format limitation or just this exporter)
faces has to be split along seams in order for each vertex to corespond
with each UV coordinate.
No performance benefits this time.
|
|
This reverts commit 7f4c2d5e48657af8bf450da7d6a0587065cfa8b4.
Issues with unit tests.
|
|
New geometry traversal code, use bmesh data instead of mesh,
much simpler logic.
This also fixes two unreported issues with exporter:
* Splitting faces when uv, vertex color or normals export options are
enabled.
* Disrupted vertex indices.
On top of that there is a significant performance improvements,
export Suzanne model with 4 subdivision levels:
* Old 4.527s
* New 1.029s
|
|
|
|
Ideally we want to use uint16 or uint32 data type for this purpose,
but certain DCCs have hardcoded uint8 limits in their PLY importers.
Silently tringulating faces with many sides is bad, but it's even worse
when correctly exported model won't load because of poor importer
implementation in other DCCs.
|
|
Issue was that in binary file reading, python only recognize `'\n'`
character as line separator... PLY seems to allow (or at least, use)
other OS-related variants of lines terminators, so we have to implement
our own line iterator for those cases...
|
|
Later I would like to show progress by percentage, but not yet sure on how to better calculate it and triger update.
|
|
|
|
Thanks to Adrian Vogelsgesang (@vogelsgesang) and his binary ply export
implementation proposal D4252.
I did not reuse any code from his patch, but it gave me a good starting point
as I had no idea how to work with binary data.
In this commit:
* Implement export to binary little-endian file format.
* Remove information about blend filename from exported file, it has no purpose.
* Binary is the default format from now on.
I cannot see any reason to implement big-endian option, if there is, please let me know.
Below you will find performance comparison between ASCII and binary formats.
Test geometry:
* Verts 379 000
* Faces 378 000
Export:
* ASCII (old) 8.0 sec
* ASCII 3.0 sec
* Binary 2.4 sec
Note: difference between old and new ASCII export is due to avoiding
unnecessary normal claculation when export normals is disabled.
Import:
ASCII 5.75 sec
Binary 4.9 sec
File sizes:
* ASCII 20.6 MB
* Binary 10.4 MB
|
|
|
|
|
|
Use dictionary comprehension instead of converting list comprehension
to dictionary. Gives around 2.5% speedup, and will probably scale in
favor of dict comprehension.
|
|
|
|
|
|
|
|
The sidebar is empty for the PLY importer, so better to hide it.
|
|
|
|
Group related and separate unrelated code, rename classes according to PEP8, remove redundant, outdated or misleading comments, greatly simplify UVs and vertex color variable init code.
|
|
F-strings are not only more readable, they also give around 10% performance increase comparing to modulo formatting. Use with statement instead of file open/close methods, safer and better practice.
|
|
Unused imports, move rare imports inside functions, comment out unused codeblocks instead of docstring, use bl_description.
|
|
D6060 now PLY exporter behaves similar to the rest of the export add-ons.
|
|
|
|
D5865 by @cmbasnett with minor edits.
|
|
Updates importers/exporters for the new file-browser design. They are
now reorganized into sub-panels.
Updated the Blender version requirement (won't be compatible with older
Blender versions). Left the Add-on versions untouched, will leave that
up to Authors to change.
|
|
|
|
Addresses new behavior of object.to_mesh().
This is corresponding part for D4875.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D4876
|
|
Mainly search-and-replace approach.
Tested the enabled-by-default export/import addons. Seems to work with
an exception of X3D which is still referencing Blender Internal material
properties.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D4866
|
|
Differential Revision: https://developer.blender.org/D4655
|
|
Differential Revision: https://developer.blender.org/D4648
|
|
|
|
|
|
|
|
|
|
Differential Revision: https://developer.blender.org/D3746
|
|
This ports the already working addons. The disabled x3d, psk, lwo, 3ds,
raw, dxf addons still need to be converted.
|
|
'TextureFile' while not officially part of the spec is often used,
so it's nice to add it back later.
|
|
Here are a couple of example files for testing: https://people.sc.fsu.edu/~jburkardt/data/ply/ply.html
I removed the texture support that was implemented here: rBA471370
(it is no official part of the file format; the exporter did not support it; reimplementing it is a bit of a hassle)
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3754
|
|
The warnings in the console are getting on the way. May as well update
the addons even if they are still mostly not ported to 2.8.
We can probably ditch orientation_helper_factory altogether.
|
|
|
|
Only default enabled addons
Give each the version: 1.0.0
|
|
These are changes to the ply and fbx export functions, and the ply
import function, to deal with vertex color alphas as implemented in the
GSoC 2017 Vertex Paint project - see T52910 & D2855
|
|
Some programs wrote extra trailing zeros.
Alternate fix to D2692.
|
|
|
|
|
|
|
|
|
|
rBAbfbabc0592b8.
Now using a class factory to allow customization of those defaults axes, still way less
verbose than previous code!
|
