Solved OBJ loading polygon order

I am writing a ptex importer and have a sneaky suspicion that the C4D OBJ loader does not maintain the order of the polygons as they are written in the file.

Has anybody else come across this?

I think I am going to have to write my own OBJ loader just to keep my own sanity about what is actually loaded and how the polygon object is created.

It could be. I never got around to investigating it any further. But if/when I do I will have a look at that flag for sure. Since in my tests there was definitely something going on with the polygon indices. Thanks for investigating this further and also for reporting your findings. Really helpful.

Cannot say it about recent versions but had exactly those troubles back in the day during production. We were using Riptide (IIRC) to import OBJ so that we could apply baked animation from point caches.

Try my plugin
https://plugincafe.maxon.net/topic/11136/plugin-import-wavefront

Thanks, everyone who takes part in this discussion.

May I ask you in which version you get this issue? Because a similar bug was fixed in R17.
If this bug is still valid for R20, could you please provide an obj that show the issue in order to create a proper bug report.

Cheers,
Maxime.

@kbar, @martinweber any news on that?
Cheers,
Maxime.

Hi Maxime,

Sorry I have had no further time to look into this. Hopefully in the next few weeks. My issue was with R20. It was an obj from the Moana dataset. I expect the polygon indices to match up with the same values within the ptex files, but it doesn't look like they do. I will need to investigate further to determine if it is the OBJ loader or not. But since people have indicated issues before that does fit with what I am experiencing. The OBJ file format has many different paths regarding how it could be loaded and interpreted. So it doesn't surprise me if one of these paths doesn't respect the polygon order.

Cheers,
Kent

@kbar I was able to load OBJs from the Moana dataset in R20 using Python and the ids did align with the Ptex face indices. My method was fairly naïve: loop from face 0 up to the ptex file's faceCount and assume they align :relaxed:

Unfortunately I was using OpenImageIO bindings that I built myself and some of the Ptex files were coming in horribly corrupted. I posted about it to the oiio mailing list but got no responses. I found that solid color tiles might be the cause of the OIIO corruption of the Ptex files and posted an example here: https://drive.google.com/open?id=1z4N3xru0_TPRxVRDoCaQ7ODAUliJRfjM

In the above case the corrupted tiles should be solid white.

Eventually I gave up on solving this through Python + OpenImageIO. I'm trying to pick C++ back up to tackle Ptex but I haven't touched it in 20 years and it's slow going :white_frowning_face: I finally managed to get Visual Studio to build the SDK examples :wink:

At any rate, I don't think there's an issue with the OBJ polygon ids in R20.

@kbar it may be a long shot, but is it possible that the OBJIMPORTOPTIONS_SPLITBY setting in the OBJ importer is set to something other than By Object?

My script would only map the Ptex correctly in that mode. Here's the applicable section of Python I used for setting up the OBJ importer:

obj_loader = plugins.FindPlugin(c4d.FORMAT_OBJ2IMPORT, c4d.PLUGINTYPE_SCENELOADER)

if obj_loader:
    data = {}
    obj_loader.Message(c4d.MSG_RETRIEVEPRIVATEDATA, data)
    bc = data['imexporter'].GetDataInstance()
    bc.SetInt32(c4d.OBJIMPORTOPTIONS_SPLITBY, 3)

It could be. I never got around to investigating it any further. But if/when I do I will have a look at that flag for sure. Since in my tests there was definitely something going on with the polygon indices. Thanks for investigating this further and also for reporting your findings. Really helpful.