#6 menu item "Seach For Missing Resources"

[simon]

whilst investigating various 3ds files ( for previous import problem;)

i noticed that for several models view3dscene is producing transparent areas, where i can see what was intended was black, this is for TGA textures.

as a quick/dirty fix i brightened the textures slightly, (got rid of exact black), and models were OK.

specifically; check out;
http://www.gfx-3d-model.com/2011/02/lamborghini-lp670-3d-model/#more-1559 shows transparent problem and also duplicate textures (see below)
http://www.gfx-3d-model.com/2011/03/horse-3d-model/#more-1672 shows tranparent problem

(regarding previous texture filename problem, BTW do the bugs need to be closed so quickly? )

i have also noticed that many texture 'packs' contain duplicates, where one copy conforms to 8.3, so i guess this is an general ongoing problem.

also, maybe of interest for previous texture linking problems

http://www.gfx-3d-model.com/2008/06/international-space-station/#more-342 shows texture linking issue

also;

http://www.gfx-3d-model.com/2008/06/house-07/#more-445

this file contains the FULL original path from the windows machine it was made on!! so for this to work at all, the path has to be removed first.

i think what is happening is that a LOT of reliance is being placed on the fact that all the files in the same folder and any sub-folders are exclusively to do with the model, or to put it another way, its like the containing folder is actually the description of the model not the 3ds file itself, if you see what i mean.

[Michalis Kamburelis]

I'll check all the links and look into the transparent problems tomorrow.

Some background: we use ImageMagick to convert TGA to PNG under the hood, and then we read PNG by libpng, so you may want to check what does "convert your_texture.tga out.png" produce. view3dcene simply uses alpha channel when PNG image has it.

As for texture filenames problems (this is continuation of #3305661 and #3304814):

The bugs are closed as soon as I consider the problem solved. I never expected someone to complain that bugs are closed too quickly :) You can still add comments to the closed bugs. If you consider the fix invalid, you can even reopen the bug, of course with some comment explaining why. Generally don't add notes to unrelated bugreport, and don't open new bugs, just to comment on a previous issue.

As for more texture filenames problems: what you observe is exactly why I consider this impossible to 100% fix in view3dscene. We can't just search everywhere looking for something barely resembling a given texture name, that's bad practice (we could dive into some deep subdirectory where user doesn't expect us to look). I also don't believe this was the intention of 3DS format. It's just that people are careless when packing 3ds+textures into a zip, which in turn means that various 3DS importers have to do more work to find the textures, which in turn means that people can be more careless... Problem is, the search algorithm isn't documented anywhere, and probably all importers do it a little differently (even our solution is already somewhat better and somewhat worse than Blender's comprehensiveImageLoad). At some point this has to stop: the bad texture filenames have to be fixed in the model, or textures must be renamed to exactly conform to what model says (this should work everywhere).

[Michalis Kamburelis]

In case of lamborghini-lp670: the transparency problem comes from different blending modes. Our default blending model has "destination = 1 - src alpha", which is consistent with other VRML/X3D browsers and generally with other 3D viewers, in my experience. Your models require "destination = one" blending mode.

In VRML/X3D you could set this using a BlendMode (present in our engine, and InstantReality, see http://vrmlengine.sourceforge.net/kambi_vrml_extensions.php#section_ext_blending ).

Maybe there is such setting in 3DS file too? And Wavefront OBJ? I'll see tomorrow. I'm pretty sure I saw some Wavefront OBJ models assuming "destination = 1 - src alpha", so I probably cannot just change the default blending mode based on imported file type (as then I would fix one example while breaking some other). We'll see tomorrow.

For now you can avoid this by using view3dscene "View->Blending Destination Factor->One". This fixes the lamborghini-lp670. Not sure yet what is wrong on horse model.

[Michalis Kamburelis]

1. lamborghini-lp670: There is no way to express in 3DS or Wavefront OBJ that Blending mode required is "destination = one". I'm guessing the screenshots on linked pages were generated from other model formats (there are Lightwave .lwo and 3dsMax .max alternatives in archive, probably one of them is source model and contains the more complete information). view3dscene default is "destination = 1 - src alpha", standard blending --- this cannot be changed, as we would break other models (including other 3ds models).

Which means: lamborgini-lp670 is unfixable: there is just not enough info in the 3DS or OBJ files to display them correctly by default. You have to use view3dscene "View->Blending Destination Factor->One" to view them Ok.

You can also export it to VRML 2.0, and manually add BlendMode node to explicitly indicate that mode destination=one should be used, this way you can make a VRML/X3D version that will be perfect (for browsers supporting BlendMode). See link in previous comment about BlendMode.

1. horse: The problem is that main texture (npc_hors.tga) is really mostly transparent. You can open it e.g. in GIMP and see. There isn't much we can do --- alpha channel of this texture should be simply ignored, but there's no such information in 3DS or Wavefront OBJ files. To view it correctly, you have to turn off "View->Blending".

As a side note, I implemented reading bump maps information from 3DS and Wavefront OBJ. This horse model has now more details visible, see the screen https://vrmlengine.svn.sourceforge.net/svnroot/vrmlengine/trunk/www/htdocs/images/original_size/horse_bump_from_3ds.png .

More side notes for this horse model: we don't support right now 3DS smoothing groups, so it doesn't look perfect. You can export to VRML and fix all creaseAngle to 4. Or you can load Wavefront OBJ version --- we correctly support normal information from Wavefront OBJ.

1. ISS checked, works, following previous fixes: PLAQUE.JPG is changed into Plaque.jpg. "PLAQUE D.JPG" will have to be fixed by user.

2. house07: (Wavefront OBJ): will open now Ok. The mechanism to search for texture filenames is extended to try stripping path from filename. And it is used for Wavefront OBJ now. And we add proper warnings, warning user that texture filename was changed (because I still believe the best solution is to fix this on user's side, to make the file valid for all 3D viewers).

As usual, all changes may be tested by http://michalis.ii.uni.wroc.pl/vrmlengine-snapshots/

[simon]

You can still add comments to the closed bugs

sorry, i didn't see how to, now i do.

having two ways to add comments, the main, obvious one, disappearing when the bug was closed, and the 'add a comment' text not indicating its active, threw me.

[simon]

so what it seems to come down too; is that the site, like others, is 'helpfully' providing multiple formats, but as is almost inevitable, the conversions they are doing have compatibility issues, (probebly worse on the newest and best models) and so it is probably only the original format, and possibly even then, only loaded into the original development software and on the same OS that is guaranteed to be right. so actually it would probably be better for them not to provide any conversions, then at least you could know what was required.

i really should have cottoned on to what the fundamental problem was, i've been hit by it enough.

i do remember thinking, 'that could save a lot of problems' when i first saw the 'interchange' profile.

BTW i got to that site because i was just looking for some nice models to try out some GLSL screen effects on. got frustrating when nothing i downloaded worked.

[simon]

would it be nice to do any 'intelligent' manipulations; like hunting for or even renaming textures, on the 'Edit' menu, where there are already the geometry repair routines, maybe in the form of some texturing repair routines. ie a 'Hunt for textures' manual option, so its clear that changes have had to be made to the original model description, and responses could be made if required, like multiple matching textures?

[Michalis Kamburelis]

Maybe a menu item "Edit -> Seach For Missing Resources (textures, scripts,...)" would be indeed useful. This would work for all nodes with "url" field, and would process them with existing texture search functions. Blender also has menu commands to aggressively search for missing external files (but then, Blender is a 3D editor, while we only try to make 3D viewer).

Renaming the bug accordingly, and moving to feature requests.

I'm not sure about this --- I would much prefer to just persuade the model creators to make correct models, with correct urls inside.