Source code:

https://github.com/c-lipka/povray/tree/feature/obj_import

Syntax is as follows:

    mesh {
      obj FILENAME
      [ OBJ_TEXTURE_LIST ]
      [ inside_vector VECTOR ]
    }

    OBJ_TEXTURE_LIST:
      texture_list {
        [ OBJ_TEXTURE_LIST_ITEM ... ]
      }

    OBJ_TEXTURE_LIST_ITEM:
      STRING texture { TEXTURE } |   (A)
      STRING material { TEXTURE } |
      prefix STRING |                (B)
      suffix STRING

At present, associated .mtl files will /not/ be evaluated; instead,
textures must be defined using one of the following means:

(A) in the texture_list, as a list of the individual material names as
used in the .obj file and the respective texture definition to use; or

(B) before the `mesh` statement, by defining texture variables with
corresponding names. For some ease of use, a pre- and suffix can be
defined that will be added to the material name as used in the .obj file.

For additional ease of use, materials can be used instead of textures;
however, in that case only the texture is taken from the material, while
the interior_texture and interior are ignored.


e.g.

    #declare MyTexture = texture { ... }
    #declare MyMaterial = material { ... }

    mesh {
      obj "MyMesh.obj"
      texture_list {
        "Foo" texture { MyTexture }
        "Bar" material { MyMaterial }
        prefix "Tx"
        suffix "_"
      }
      inside_vector y
    }

will map the material name "Foo" in the .obj file to `MyTexture` and the
material name "Bar" to `MyMaterial`, while any other name, say, `Fnord`
or `Uqbar`, would be mapped to `TxFnord_` and `TxUqbar_`, respectively.


OBJ import provides rudimentary support for non-triangular polygons, but
currently just blindly cuts up such polygons into triangles, relying on
the polygons to be nicely planar and convex. This may also affect the
apparent curvature of such polygons.


That said, I have a hunch that someone might like this feature.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
[snip]

Excellent! This will be very useful. Almost everything can export to obj, so
this immediately improves workflow for any project that uses a third-party
modeller.

Presumably the slight increase in read speed over mesh2 stems from the fact that
..obj is slightly less verbose in its syntax?

Bill

Post a reply to this message

Am 14.09.2016 um 07:18 schrieb Bill Pragnell:
> clipka <ano### [at] anonymousorg> wrote:
> [snip]
> 
> Excellent! This will be very useful. Almost everything can export to obj, so
> this immediately improves workflow for any project that uses a third-party
> modeller.

That of course depends on the quality of the exporter. If it exports
poor meshes, with flipped normals and stuff, an external tool like
PoseRay is still recommended.


> Presumably the slight increase in read speed over mesh2 stems from the fact that
> ...obj is slightly less verbose in its syntax?

Exactly.

Post a reply to this message

On 9/13/2016 8:08 PM, clipka wrote:
> That said, I have a hunch that someone might like this feature.
>

It's been documented: http://wiki.povray.org/content/Reference:Mesh

I also created a talk page in case it's needed.

Post a reply to this message

Am 14.09.2016 um 22:10 schrieb Jim Holsenback:
> On 9/13/2016 8:08 PM, clipka wrote:
>> That said, I have a hunch that someone might like this feature.
>>
> 
> It's been documented: http://wiki.povray.org/content/Reference:Mesh
> 
> I also created a talk page in case it's needed.

Thanks; I guess I'll have to hurry to integrate it into the official
branch then ;)

Post a reply to this message

On 9/14/2016 4:40 PM, clipka wrote:
> Am 14.09.2016 um 22:10 schrieb Jim Holsenback:
>> On 9/13/2016 8:08 PM, clipka wrote:
>>> That said, I have a hunch that someone might like this feature.
>>>
>>
>> It's been documented: http://wiki.povray.org/content/Reference:Mesh
>>
>> I also created a talk page in case it's needed.
>
> Thanks; I guess I'll have to hurry to integrate it into the official
> branch then ;)
>
why the limitation of interior when material is used? that would leave 
out a glass object just to name one

Post a reply to this message

Am 14.09.2016 um 23:43 schrieb Jim Holsenback:
> On 9/14/2016 4:40 PM, clipka wrote:
>> Am 14.09.2016 um 22:10 schrieb Jim Holsenback:
>>> On 9/13/2016 8:08 PM, clipka wrote:
>>>> That said, I have a hunch that someone might like this feature.
>>>>
>>>
>>> It's been documented: http://wiki.povray.org/content/Reference:Mesh
>>>
>>> I also created a talk page in case it's needed.
>>
>> Thanks; I guess I'll have to hurry to integrate it into the official
>> branch then ;)
>>
> why the limitation of interior when material is used? that would leave
> out a glass object just to name one

Because POV-Ray's architecture currently doesn't support different
interiors in a single primitive (which may not even make much sense),
and OBJ import is currently designed to generate a single mesh.

You can always add an interior to the entire mesh as part of the
OBJECT_MODIFIERS.

Post a reply to this message

On 09/14/2016 04:10 PM, Jim Holsenback wrote:
> On 9/13/2016 8:08 PM, clipka wrote:
>> That said, I have a hunch that someone might like this feature.
>>
>
> It's been documented: http://wiki.povray.org/content/Reference:Mesh
>
> I also created a talk page in case it's needed.
>
Now I know who has the real power to get things into the master branch :-).

FYI - A new object in the "lemon" is in the master branch and not yet 
documented in povray's documentation. Jérôme has some documentation for 
it already on his page at:

   http://wiki.povray.org/content/User:Le_Forgeron#Lemon

Unsure if on yours or Jérôme's todo list. If I can help in some way 
update the docs for the lemon, let me know.

Bill P.

Post a reply to this message

On 9/15/2016 7:13 AM, William F Pokorny wrote:
> FYI - A new object in the "lemon" is in the master branch and not yet
> documented in povray's documentation. Jérôme has some documentation for
> it already on his page at:

it's been added http://wiki.povray.org/content/Reference:Lemon

looks like the opening paragraph could use some help so I also created a 
talk page as well: http://wiki.povray.org/content/Reference_Talk:Lemon

Post a reply to this message

On 09/15/2016 12:03 PM, Jim Holsenback wrote:
> On 9/15/2016 7:13 AM, William F Pokorny wrote:
>> FYI - A new object in the "lemon" is in the master branch and not yet
>> documented in povray's documentation. Jérôme has some documentation for
>> it already on his page at:
>
> it's been added http://wiki.povray.org/content/Reference:Lemon
>
> looks like the opening paragraph could use some help so I also created a
> talk page as well: http://wiki.povray.org/content/Reference_Talk:Lemon
>

Thanks. I've attempted some descriptive text at:

http://wiki.povray.org/content/Reference_Talk:Lemon

Bill P.

Post a reply to this message

Le 15/09/2016 à 18:59, William F Pokorny a écrit :
> On 09/15/2016 12:03 PM, Jim Holsenback wrote:
>> On 9/15/2016 7:13 AM, William F Pokorny wrote:
>>> FYI - A new object in the "lemon" is in the master branch and not yet
>>> documented in povray's documentation. Jérôme has some documentation for
>>> it already on his page at:
>>
>> it's been added http://wiki.povray.org/content/Reference:Lemon
>>
>> looks like the opening paragraph could use some help so I also created a
>> talk page as well: http://wiki.povray.org/content/Reference_Talk:Lemon
>>
> 
> Thanks. I've attempted some descriptive text at:
> 
> http://wiki.povray.org/content/Reference_Talk:Lemon
> 
> Bill P.

I like it, but the introducing description is a bit harsh for the
non-mathematically-addicted.
So I added a bit in the discussion too

Post a reply to this message

On 9/15/2016 12:59 PM, William F Pokorny wrote:
> On 09/15/2016 12:03 PM, Jim Holsenback wrote:
>> On 9/15/2016 7:13 AM, William F Pokorny wrote:
>>> FYI - A new object in the "lemon" is in the master branch and not yet
>>> documented in povray's documentation. Jérôme has some documentation for
>>> it already on his page at:
>>
>> it's been added http://wiki.povray.org/content/Reference:Lemon
>>
>> looks like the opening paragraph could use some help so I also created a
>> talk page as well: http://wiki.povray.org/content/Reference_Talk:Lemon
>>
>
> Thanks. I've attempted some descriptive text at:
>
> http://wiki.povray.org/content/Reference_Talk:Lemon

a combination of both: http://wiki.povray.org/content/Reference:Lemon

Post a reply to this message

Le 16/09/2016 à 00:34, Jim Holsenback a écrit :
> On 9/15/2016 12:59 PM, William F Pokorny wrote:
>> On 09/15/2016 12:03 PM, Jim Holsenback wrote:
>>> On 9/15/2016 7:13 AM, William F Pokorny wrote:
>>>> FYI - A new object in the "lemon" is in the master branch and not yet
>>>> documented in povray's documentation. Jérôme has some documentation for
>>>> it already on his page at:
>>>
>>> it's been added http://wiki.povray.org/content/Reference:Lemon
>>>
>>> looks like the opening paragraph could use some help so I also created a
>>> talk page as well: http://wiki.povray.org/content/Reference_Talk:Lemon
>>>
>>
>> Thanks. I've attempted some descriptive text at:
>>
>> http://wiki.povray.org/content/Reference_Talk:Lemon
>
> a combination of both: http://wiki.povray.org/content/Reference:Lemon
>

I really liked the passage about the american football and other real 
evocations. It gave flesh to the description.



The constraint on minimal inner_radius is really a dangerous beast:


If base & cap radius are both 0, the inner_radius must be at least half 
the distance between base and cap point (it would be a sphere)

So, as stated, the doc is false.


If base & cap radius are identical, the minimal inner_radius would be 
sqrt( radius² + (distance/2)² ) , where distance is the length between 
base and cap points.

when base & cap radius are different, it become nightmare (the exact 
equation is in the code, if you dare to want to know it).

Post a reply to this message

On 9/16/2016 4:08 AM, Le_Forgeron wrote:
> The constraint on minimal inner_radius is really a dangerous beast:
>
>
> If base & cap radius are both 0, the inner_radius must be at least half
> the distance between base and cap point (it would be a sphere)
>
> So, as stated, the doc is false.
>
>
> If base & cap radius are identical, the minimal inner_radius would be
> sqrt( radius² + (distance/2)² ) , where distance is the length between
> base and cap points.
>
> when base & cap radius are different, it become nightmare (the exact
> equation is in the code, if you dare to want to know it).

no worries /but/ i wish you'd been as verbose with your previous post 
... however i see a bit of a conflict (perhaps i've characterized 
incorrectly) item 4 and 5 seem a bit murky or are the /both/ correct:

http://wiki.povray.org/content/Reference:Lemon

Post a reply to this message

On 09/16/2016 04:08 AM, Le_Forgeron wrote:
> Le 16/09/2016 à 00:34, Jim Holsenback a écrit :
>> On 9/15/2016 12:59 PM, William F Pokorny wrote:
>>> On 09/15/2016 12:03 PM, Jim Holsenback wrote:
>>>
>>> Thanks. I've attempted some descriptive text at:
>>>
>>> http://wiki.povray.org/content/Reference_Talk:Lemon
>>
>> a combination of both: http://wiki.povray.org/content/Reference:Lemon
>>
>
> I really liked the passage about the american football and other real
> evocations. It gave flesh to the description.
>
>
>
> The constraint on minimal inner_radius is really a dangerous beast:
>
>
> If base & cap radius are both 0, the inner_radius must be at least half
> the distance between base and cap point (it would be a sphere)
>
> So, as stated, the doc is false.
>
>
> If base & cap radius are identical, the minimal inner_radius would be
> sqrt( radius² + (distance/2)² ) , where distance is the length between
> base and cap points.
>
> when base & cap radius are different, it become nightmare (the exact
> equation is in the code, if you dare to want to know it).
>

Argh. Sorry Jim. I got the wording for what I believe is the lower-most 
bound for the inner radius wrong. I had in my head only to offer general 
guidance there.

Adding the full equations is an option I guess - we do for other objects 
in the docs. If we stick with a general description, we could build on 
what you, Jérôme, wrote with perhaps:

If base & cap radius are both 0, the inner_radius must be at least half
the distance between base and cap point (it would be a sphere). 
Otherwise the minimum inner radius is larger than half the distance 
between base and cap point. Any time the inner radius given is too 
small, the code uses the minimum radius over the specified one and 
issues a warning.

Bill P.

Post a reply to this message

On 09/16/2016 08:53 AM, Jim Holsenback wrote:
> On 9/16/2016 4:08 AM, Le_Forgeron wrote:
>> The constraint on minimal inner_radius is really a dangerous beast:
>>
>>
>> If base & cap radius are both 0, the inner_radius must be at least half
>> the distance between base and cap point (it would be a sphere)
>>
>> So, as stated, the doc is false.
>>
>>
>> If base & cap radius are identical, the minimal inner_radius would be
>> sqrt( radius² + (distance/2)² ) , where distance is the length between
>> base and cap points.
>>
>> when base & cap radius are different, it become nightmare (the exact
>> equation is in the code, if you dare to want to know it).
>
> no worries /but/ i wish you'd been as verbose with your previous post
> ... however i see a bit of a conflict (perhaps i've characterized
> incorrectly) item 4 and 5 seem a bit murky or are the /both/ correct:
>
> http://wiki.povray.org/content/Reference:Lemon
>
>

I believe we need to delete the following list item (me originally 
leading you wrong I think):

* generally speaking Inner_Radius must be greater than or equal to the 
distance between end points

or change it to:

* generally speaking the Inner_Radius must be greater than or equal to 
half the distance between end points

Bill P.

Post a reply to this message

On 9/16/2016 9:33 AM, William F Pokorny wrote:
> Argh. Sorry Jim. I got the wording for what I believe is the lower-most
> bound for the inner radius wrong. I had in my head only to offer general
> guidance there.

like i said ... no worries

>
> Adding the full equations is an option I guess - we do for other objects
> in the docs. If we stick with a general description, we could build on
> what you, Jérôme, wrote with perhaps:

sticking with general description

>
> If base & cap radius are both 0, the inner_radius must be at least half
> the distance between base and cap point (it would be a sphere).
> Otherwise the minimum inner radius is larger than half the distance
> between base and cap point. Any time the inner radius given is too
> small, the code uses the minimum radius over the specified one and
> issues a warning.

i /think/ i've got it this time: 
http://wiki.povray.org/content/Reference:Lemon

Post a reply to this message

Le 16/09/2016 à 16:41, Jim Holsenback a écrit :
> On 9/16/2016 9:33 AM, William F Pokorny wrote:
>> Argh. Sorry Jim. I got the wording for what I believe is the lower-most
>> bound for the inner radius wrong. I had in my head only to offer general
>> guidance there.
> 
> like i said ... no worries
> 
>>
>> Adding the full equations is an option I guess - we do for other objects
>> in the docs. If we stick with a general description, we could build on
>> what you, Jérôme, wrote with perhaps:
> 
> sticking with general description
> 
>>
>> If base & cap radius are both 0, the inner_radius must be at least half
>> the distance between base and cap point (it would be a sphere).
>> Otherwise the minimum inner radius is larger than half the distance
>> between base and cap point. Any time the inner radius given is too
>> small, the code uses the minimum radius over the specified one and
>> issues a warning.
> 
> i /think/ i've got it this time:
> http://wiki.povray.org/content/Reference:Lemon
> 

I added yet another comment in the discussion.

Post a reply to this message

On 9/16/2016 12:05 PM, Le_Forgeron wrote:
> I added yet another comment in the discussion.

http://wiki.povray.org/content/Reference:Lemon

Post a reply to this message

On 09/17/2016 08:57 AM, Jim Holsenback wrote:
> On 9/16/2016 12:05 PM, Le_Forgeron wrote:
>> I added yet another comment in the discussion.
>
> http://wiki.povray.org/content/Reference:Lemon
>
>

Suggesting a correction and further tweak at bottom of the page:

http://wiki.povray.org/content/Reference_Talk:Lemon

Bill P.

Post a reply to this message

On 9/17/2016 9:52 AM, William F Pokorny wrote:
> Suggesting a correction and further tweak at bottom of the page:

i had it there previously had it but thought it looked better where i 
had it ... oh well moved/updated it

Post a reply to this message

On 9/17/2016 10:14 AM, Jim Holsenback wrote:
> i had it there previously had it but thought it looked better where i
> had it ... oh well moved/updated it

i had it there previously but thought it looked better where i had it 
... oh well moved/updated it ... sheesh

Post a reply to this message

On 9/17/2016 10:15 AM, Jim Holsenback wrote:
> i had it there previously but thought it looked better where i had it
> ... oh well moved/updated it

updated image and example code: 
http://wiki.povray.org/content/Reference:Lemon

Post a reply to this message

Le 19/09/2016 à 02:56, Jim Holsenback a écrit :
> On 9/17/2016 10:15 AM, Jim Holsenback wrote:
>> i had it there previously but thought it looked better where i had it
>> ... oh well moved/updated it
>
> updated image and example code:
> http://wiki.povray.org/content/Reference:Lemon
>
>

The following point still does not make sense:

* minimal Inner_Radius is a spherical segment where the center of the 
arc lies on the end points axis

Please see the discussion for the original sentence.

Post a reply to this message

On 9/19/2016 7:20 AM, Le_Forgeron wrote:
> Le 19/09/2016 à 02:56, Jim Holsenback a écrit :
>> On 9/17/2016 10:15 AM, Jim Holsenback wrote:
>>> i had it there previously but thought it looked better where i had it
>>> ... oh well moved/updated it
>>
>> updated image and example code:
>> http://wiki.povray.org/content/Reference:Lemon
>>
>>
>
> The following point still does not make sense:
>
> * minimal Inner_Radius is a spherical segment where the center of the
> arc lies on the end points axis
>
> Please see the discussion for the original sentence.

oh-key-doe-key then ...

Post a reply to this message

Le 19/09/2016 à 15:12, Jim Holsenback a écrit :
> On 9/19/2016 7:20 AM, Le_Forgeron wrote:
>> Le 19/09/2016 à 02:56, Jim Holsenback a écrit :
>>> On 9/17/2016 10:15 AM, Jim Holsenback wrote:
>>>> i had it there previously but thought it looked better where i had it
>>>> ... oh well moved/updated it
>>>
>>> updated image and example code:
>>> http://wiki.povray.org/content/Reference:Lemon
>>>
>>>
>>
>> The following point still does not make sense:
>>
>> * minimal Inner_Radius is a spherical segment where the center of the
>> arc lies on the end points axis
>>
>> Please see the discussion for the original sentence.
> 
> oh-key-doe-key then ...

thanks. Remember that I'm not a native speaker, so it's ok to amend any
of my text, as long as I can still understand it.

Post a reply to this message

Folks, just to let you know: Don't get too accustomed to the exact
syntax; I have strong reason to suspect I'll change it.

For starters, there may be cases when you want to import an .obj not as
a single mesh but as a set of meshes. (Point in case: Poser or DAZ
figures with eyelashes; the skin should have a refractive index of
around 1.45 for the Fresnelian effects to be modeled properly, while the
eyelashes must not have a refractive index at all or they'll look weird;
and while we're at it, the teeth should have a reflective index of
around 1.6. But POV-Ray does not support different refractive indices in
a single mesh.) The .obj mesh import syntax could be changed to import
only geometry that matches certain criteria (based on material, group or
object), but this would mean that in order to import all parts of an
.obj file it would have to be parsed multiple times, which isn't efficient.

So the approach I'll probably take is to make the obj import feature
create a single mesh if no filtering is done, but also provide means to
create a CSG union of meshes. But obviously it would be a tad confusing
to have a `mesh` statement create a CSG.

Also, in case we ever extend the import to support non-mesh geometry
(obj also supports points, lines and various NURBS-ish stuff) or even
other file formats that may support genuine geometric primitives,
stuffing all of it into the `mesh` syntax would seem rather odd.

Post a reply to this message

I am looking forward to this. One of the (future) benchmarks will 
probably be when the import of a (complex) Poser figure will become 
standard procedure :-)

However, I can also imagine other interesting complex things...

Good work! Thank you indeed for your unrelenting dedication!

-- 
Thomas

Post a reply to this message

On 9/22/2016 8:49 AM, Thomas de Groot wrote:
> I am looking forward to this. One of the (future) benchmarks will
> probably be when the import of a (complex) Poser figure will become
> standard procedure :-)
>
> However, I can also imagine other interesting complex things...
>
> Good work! Thank you indeed for your unrelenting dedication!
>

Seconded.

Bravo.


-- 

Regards
     Stephen

Post a reply to this message

Am 22.09.2016 um 09:49 schrieb Thomas de Groot:
> I am looking forward to this. One of the (future) benchmarks will
> probably be when the import of a (complex) Poser figure will become
> standard procedure :-)

Actually I'm aiming for import of DAZ figures...

... which is why JSON import is next on my list (DAZ Studio 4.x's .duf
file format is actually based on JSON), in order to provide a vector for
the import of arbitrary DAZ materials. (The .mtl files that accompany
.obj files are far too restricted to be of any practical use with DAZ
figures.) The envisioned workflow would be (1) export of materials from
DAZ as (uncompressed) material presets, (2) import into POV-Ray using an
inbuilt syntax for JSON files, (3) processing of the imported data via
SDL macros to generate a set of POV-Ray material and texture
definitions, and (4) association of those materials to the meshes.

Which in turn means I'll have to implement yet a few more SDL goodies,
most notably mixed-type arrays. Some means to iterate over the elements
of a dictionary will also be needed, and possibly also a means to
identify what type of data a given variable holds.

And of course someone will have to implement a default include file to
actually do the DAZ materials data processing.

Post a reply to this message

On 22-9-2016 16:08, clipka wrote:
> Am 22.09.2016 um 09:49 schrieb Thomas de Groot:
>> I am looking forward to this. One of the (future) benchmarks will
>> probably be when the import of a (complex) Poser figure will become
>> standard procedure :-)
>
> Actually I'm aiming for import of DAZ figures...
>

Hmm. I suppose that is ok, although /personally/ I am no fan of DAZ for 
different reasons and prefer Poser, with all its inherent weaknesses.

-- 
Thomas

Post a reply to this message