Failure to load/process very basic model [ply textures + bounding box far from the origin]

[TJRL]

I'm trying to load a very simple single res ply file (a plane with a texture) in 3DHOP, but for some reason the texture (tried png and jpg) does not show. Also, hoping it would help, I tried to process it with nexus, but the program simply quit. I tried a countless number of things, exporting from Blender to Meshlab with various file formats and different ways of adding textures, but I cant solve the problem. It is unclear to me what goes wrong since nexus gives no feedback, and quits before I can see anything.

I have had previous problems with models not being accepted by nexus. It was solved by unselecting 'export normals' in meshlab. This however doesnt do the trick here.

Link to the model: http://www.4dresearchlab.nl/3DHOP/MT/models/google/MT_Gmaps.ply

[TJRL]

So, I finally 'solved' it by making the plane a box by extrusion. I still don't get why the plane was not accepted by 3DHOP and nexus.

[potenziani]

Hi @TJRL , thanks for reporting this strange behavior!

I made different tests with your 3D model (using a test texture, since your link doesn't contain the jpg file), but unfortunately I wasn't able to replicate your problem.

In this archive you can find both Nexus and Ply models I used in my tests (got starting from the model you provided).

Since PLY is not our "core" format, using PLY in 3DHOP is a little bit tricky... For instance, texture mapping has to be per-vertex (in your model was per-wedge). Also, texture files resolution has to be a square power of two (128x128, 256x256, 512x512, 1024x1024, etc)... Could these factors be the cause of your issue?

Conversely, usually the Nexus conversion is quite straightforward... In this case I got the multiresolution files in the attached zip simply using the drag&drop procedure (with Nexus 4.2). Could your issue be caused by a particular texture file? Did you try to use the command line conversion for getting details about your error?

Anyway, to better cope with issues like these we just updated the model preparation guide, so you can read it when you have problems in visualizing models in 3DHOP.

Ps: I noticed your model is just a plane with a texture... I don't know what's the final purpose of your project, but are you sure that a 3D viewer is the best option to get this media online? Maybe you would prefer a multiresolution engine for hi-res 2D images? (like for instance relight ...)

[TJRL]

Hi @potenziani ,

sorry, I had already updated the model so you downloaded a version that worked... The model that gives issues is this one (now including the texture file)

I did another test using command line this time. It tells me the bounding box is far from the origin (with respect to its size), the model MIGHT be quantized. But I don't uderstand as the origin is exactly in the middle...

The texture is 1792x1024 indeed. So not a square power of 2 for the width. However, the same texture works fine on the other model, the one I linked to you in my previous post.

About per vertex/per wedge texture mapping: you say it requires vertex mapping, but I followed this manual which states texture mapping had to be per wedge rather than per vertex.

Finally, I needed the simple plane with a texture as a backdrop for a multi resolution model of lidar data. You can see it in action here. We used it last weekend to have children play with light and measurement to teach something about the uses of aerial photography, LIDAR and DEMs in archaeology :)

Thanks for taking the time to respond!!

[potenziani]

Hi @TJRL, when I wrote about textures resolution and per-vertex mapping, I was referring to PLY models visualized as it, without any conversion. Instead, to get a multiresolution Nexus model your input PLY doesn't need either per vertex mapping and square-power-of-2 side resolution. I know this can be confusing, but this is the reason why I told you that the management of PLY is quite raw... Indeed, the model preparation guide has been updated specifically for better clarifying these points.

Ps: your link is broken, please check it.

[TJRL]

Ah, I understand. Thanks for updating!

I updated the link!

[potenziani]

Hi @TJRL , ok, now everything is clear. Processing your PLY in Nexus you got this error message

WARNING: The bounding box is far from the origin (with respect to its size),
the model MIGHT be quantized.
In that case use MeshLab or CloudCompare to move the model closer to the origin
Fatal error: ERROR: Quantization is too severe, quitting

But as you said

I don't understand as the origin is exactly in the middle...

And you are almost right because your model (or bounding box) is near to the origin... but actually, it is not near enough! :-)

Let me explain, this is what you have:

And zooming on the bounding box panel we can see this:

So, as you can see from the first image (and also reading the "center" line in the bounding box panel) your model/bbox isn't really in the origin, but it is slightly translated ~[-155, -108, 74]. Usually, this is not a big problem for Nexus. But it becomes a critical error with the specific shape of your model/bbox. Indeed, if you remember, the error message said ...the bounding box is far from the origin (WITH RESPECT TO ITS SIZE).... And your 3D model is a 2D plane with bounding box size ~[3311, 0, 1892] (line "size" in the bounding box panel)! Without delving into the technicalities, the fact that the model/bbox is translated along the Y axes (-108), unfortunately in this case creates quantization issues in Nexus since the Y size of your model/bbox is 0...

This is also the reason why you solved the problem by making the plane a box by extrusion (and so, giving to the Y size a value different from 0).

However, there is a simpler workaround to solve problems like this: ... use MeshLab or CloudCompare to move the model closer to the origin... (again, from the error message).

For doing that, in MeshLab, you just have to apply this filter:

Filters -> Normals, Curvatures, and Orientation -> Transform: Translate, Center, set Origin

choosing "Center on BBox" as Transformation ("Ctrl+H" to recenter the trackball if the model disappears).

With your model you will get this:

and this:

So, again a flat model, but this time exactly centered in the origin... and perfectly positioned to meet the Nexus requirements!

[TJRL]

Super thanks for the elaborate answer @potenziani I learned something new today :) (and I should have looked closer at where my origin actually was, I just thought: 'meeee, sort of in the middle, should be alright', clearly I was thinking like a human, not like nexus' algorithm ;))