| Age | Commit message (Collapse) | Author |
|---|
|
|
|
By now I'm not aware of any serious regressions or missing functionality
in the C++ based OBJ importer/exporter. They have more features (vertex colors
support), and are way faster than the Python based importer/exporter.
Reviewed By: Thomas Dinges, Howard Trickey
Differential Revision: https://developer.blender.org/D15360
|
|
This is no longer necessary, see: T98554.
|
|
|
|
While it still has known issues/bugs/limitations. Also related: D14512.
Differential: D14513
|
|
|
|
See T95597
|
|
This reverts commit d364a7b4253e974ad3cc5c76e08478fa69ca0a46.
|
|
The previous commits to split the obj importer/exporter into two
had the bad side effect of breaking the Python API for the importer
and exporter. So it was reverted and this less drastic method is used:
just don't put the python exporter into the menu. This way the
old scripts using bpy.ops.import_scene.import and .export will still
work (at least until we remove them completely in a future release).
The new obj exporter can be accessed in python right now as
bpy.ops.wm.export_obj(), which is probably not the best name but that
can be fixed later.
|
|
This reverts commit a811876bc7f2ea7e42cfe2c2512ac5a95e40f006.
|
|
Also put an " - Old" by the name of the exporter.
The intention is that we won't load the Python exporter, but if a user wants
it, they can enable that addon.
|
|
Also put an " - Old" by the name of the exporter.
The intention is that we won't load the Python exporter, but if a user wants
it, they can enable that addon.
|
|
The addon would assume an OBJ range of [0.0-900.0] for the Ns value,
when it actually is supposed to be [0.0-1000.0].
WARNING: This is introducing a slight incompatibility (value shifting of
the roughness parameter) with older OBJ files exported by Blender.
|
|
|
|
Also remove commented `use_mesh_modifiers_render` option which is
unlikely to be added back since this option no longer exists internally.
|
|
OBJ files require that parameters are specified after every line start element except the "end" command.
This patch skips all lines that are missing that information unless there is a multi line context.
Reviewed By: mont29
Maniphest Tasks: T83671
Differential Revision: https://developer.blender.org/D9828
|
|
In rBA6aa8e130eff59059886e203ff95221609f63b222 all occurrences
of "lamp" where replaced with "light" which also accidentally
renamed "clamp" to "clight". In case of the x3d importer and
object carver add-on this broke some functionality. This
commit fixes the names to match the use the correct properties
of the Python API and use semantically correct names for other
add-on where the renaming didn't cause functional changes.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D9782
|
|
Since panels of importer are defined after the operator, do the same for
the exporter...
|
|
Please do not commit random things to code maintained by other people,
especially if you are breaking basic 101 things like codestyle. This is
loss of time for everybody. Even worse since not ansewring to comments
on original commit.
Also no need to add extra `text` parameters (and more useless UI
messages) in add-ons, when the only usage of the property's name itself
is in own add-on' UI...
|
|
|
|
|
|
|
|
|
|
Looks like a plain oversight in rBA53aec1ccff1b.
Maniphest Tasks: T72558
Differential Revision: https://developer.blender.org/D6448
|
|
|
|
MTL standard does consider g and b values as optional...
|
|
|
|
Changes in UI are significant enough to justify it.
|
|
See e4de25e78b59e9.
|
|
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.
|
|
Reviewers: mont29
Maniphest Tasks: T68618
Differential Revision: https://developer.blender.org/D5479
|
|
|
|
Looks like loose edges need to be properly tagged as such nowadays...
|
|
Clamp input values to avoid invalid ones.
|
|
|
|
2.79b.
While this is not officialy part of OBJ format, some softwares 'solve'
the spaces-in-filenames issue by delimiting those with quotes.
Since this is not too much a hassle, let's add back support for this.
Based on work from Robert Guetzkow (@rjg), thanks.
Note: not sure whether this should be ported to 2.80 release, while this
change should be reasonably safe, it's not an obvious one-liner either,
and the issue is not really critical (don’t think any major software
uses that trick?)...
|
|
|
|
Caused by rB8252cc7044ea (fix for T65215), we actually need a default
material in edges-only case too, not to exclude None (default) one in
that case...
|
|
fails on re-import if object has adges but no faces.
|
|
Much better than using Principled's Transmission setting as we did
before...
Part of T64609.
|
|
We need a way for add-ons to generate a temp render depsgraph and
evaluate it, for this to work again, with new Blender 2.8 design.
|
|
Not really important here (we expect to set a value for all items), but
avoids useless computation anyway.
|
|
We cannot clear a face's vnors/uvs indices in case none are defined in
the OBJ file, we need indices for all loops when defining them in
Blender's mesh...
|
|
instances.
Looks like that was skipped somehow when OBJ IO was ported to 2.8...
|
|
As discussed in D4303.
|
|
Regression/side effect from rBA9448cef00d1b3, while we do want to get
one Blender object per 'o' line (object declaration) in OBJ file, we do
want to 'reuse' same objects when same OBJ groups ('g' lines) are used
inside of a same object, in case we split OBJ groups into objects...
Thanks to Jacques Lucke (@JacquesLucke) for initial investigation.
|
|
Bloody stupid mistake in 'speed-up parsing' work, yet annoyingly
difficult to spot on... :(
|
|
named the same.
Ensure we use a different key for each OBJ object (usung similar naming
increment as Blender one).
|
|
Issue noticed by Philipp Oeser (@lichtwerk), thanks!
|
|
|
