[LDView][LDCad] Bug rendering 49098.dat

[Bertrand Lequy]

Hi, I was creating instructions with LPub3D when I encountered this bug.

The torus subpart of https://www.ldraw.org/parts/official-par...rtid=49098 isn't rendered.

I investigate a bit and notice there's no consistency in this bug. Even here on LDraw.org.
Coming next are screenshots of this part as viewed by several softwares :

in the part tracker :
- this one is a 200% view of the PT's thumbnails (maybe generated with LDView ?)


- this one is from the PT's 3D viewer, part is complete, yay !

- in LDView, note that the tree info module shows the primitive and knows that the quads should be rendered (red highlight) :

- in MLCad (the old man knows how do deal with parts) :

- LDCad  (BFC is working here) :


- LPub3D 200% PLI display unsing LDView (since LDView doesn't render the part correctly, it's obvious this one isn't correct) :

- LPub3D with the native rendering engine (works fine) :


- Last but not least, I inlined the torus primitive and "ta-da !" :

LDView finaly rendered the file nicely.

I can't remember when, but it's a bypass I allready used this year and that we discussed here. I used (maybe badly) the search option of the forum and didn't find the thread.

EDIT : The problem still exists in LPub3D

[Travis Cobbs]

The last time something like this happened, it was due to the torus primitive having the wrong filename. In other words, its filename indicated that it was one size, but the geometry inside was another size. Something similar appears to be the case here as well. When LDView performs primitive substitution, it relies purely on the filename to decide what the primitive is supposed to look like. So if the filename is wrong, the primitive will be drawn wrong. If you look closely, you will see that 48/tm04o2727.dat is being drawn quite small in the middle of the hub when primitive substitution is enabled in LDView.

I looked at 48/tm04o2727.dat, and despite being an official file (!), it appears to be totally broken. As far as I can tell, it has been scaled up to be 14 LDU in radius, instead of 1.2727 like it is supposed to be. In other words, its geometry is 11 times bigger than it is supposed to be. So, while it's supposed to be scaled up by a factor of 22 in the X and Z axes to work in this part, it is instead only scaled up by 2.

If you disable primitive substitution in LDView, you will see the original primitive geometry, instead of the geometry indicated by the filename. Similarly, if you select any of the geometry inside the torus primitive in the model tree, it will draw the geometry from the file. Since the geometry in the file is wrong, it gives you the behavior you see. LDView is behaving exactly as designed, and will not be changed.

[Travis Cobbs]

One more note. The 48\tm04o2727.dat file needs to be fixed, but since it is official, it is presumably used in at least one official part, and that part also needs to be fixed. If you look at the comments in the file, you can see that it was generated wrong:

0 // Generated by LDraw Torus Generator
0 // Major Radius: 11
0 // Tube(Minor) Radius: 3


Also note that since it is official, LDView will display the official version even if a fixed version is placed on the parts tracker. The only way to see how it will behave is to manually replace the actual official file with the fixed unofficial one. This is also by design, since LDView assumes that official files will never be broken. It therefor always prefers them over unofficial files.

Edit: I just noticed that the original file that uses this primitive is an official file. I hadn't noticed that originally. It could be that this is the only file that uses that primitive, but if that is not the case, then all files using the primitive will have to be fixed.

Edit 2: The "LDraw Torus Generator" is, IMO, broken. It should either not allow you to generate an invalid torus, or it should at least warn you that an invalid torus must not be used as an LDraw primitive. Major radius 11 with minor radius 3 will never be a valid LDraw primitive.

[Bertrand Lequy]

If you disable primitive substitution in LDView, you will see the original primitive geometry, instead of the geometry indicated by the filename. Similarly, if you select any of the geometry inside the torus primitive in the model tree, it will draw the geometry from the file. Since the geometry in the file is wrong, it gives you the behavior you see. LDView is behaving exactly as designed, and will not be changed.

Thank you for your explanations.

I didn't mean that LDView or LDCad were responsible, I just noticed that there was a problem and tried to expose it at my best (wich is not good apparently) There was no offence intended.

Obviously, if MLCad or LPub3D renderer don't perform primitive substitution, they can't encounter this issue.

[Travis Cobbs]

Thank you for your explanations.

You're welcome. To be clear, I wasn't upset by your report.

[Philippe Hurbain]

Edit 2: The "LDraw Torus Generator" is, IMO, broken. It should either not allow you to generate an invalid torus, or it should at least warn you that an invalid torus must not be used as an LDraw primitive. Major radius 11 with minor radius 3 will never be a valid LDraw primitive.

Not really broken, but there is a "normalize major radius" button that must be checked. Misleading indeed... 
http://ldtorgen.appspot.com/

[Travis Cobbs]

Not really broken, but there is a "normalize major radius" button that must be checked. Misleading indeed... 
http://ldtorgen.appspot.com/

Since it seems to actively encourage the generation of files that are invalid LDraw primitives, I personally feel that that rises to the level of being a bug. (This is only the case if the normal use case for the tool is generating LDraw primitives. It is my belief that this is so, but I could be wrong about that.)

[Magnus Forsberg]

Not really broken, but there is a "normalize major radius" button that must be checked. Misleading indeed... 
http://ldtorgen.appspot.com/

Yes, don't blame the generator. The blame is all mine. This is the second time (or maybe this was the first) I have created a bad mixed mode torus.
Funny that no one found it until now.

This prim is only used in this part and a fix is already done and in the mail.

[Bertrand Lequy]

Yes, don't blame the generator. The blame is all mine. This is the second time (or maybe this was the first) I have created a bad mixed mode torus.
Funny that no one found it until now.

This prim is only used in this part and a fix is already done and in the mail.

I replaced the wrong files with your fixes and LPub3D rendered 49098 right using LDView. Thank you.

[Travis Cobbs]

Yes, don't blame the generator. The blame is all mine. This is the second time (or maybe this was the first) I have created a bad mixed mode torus.
Funny that no one found it until now.

This prim is only used in this part and a fix is already done and in the mail.

Saying that a piece of software has a bug isn't really "blaming" that software. I want to be clear that when I stated that it was my opinion that this was a bug, I was not bad-mouthing the torus generator. All software has bugs. LDView (which I mostly wrote) currently has a number of known bugs, as well as an almost certainly greater number of unknown bugs. That is the nature of software. Now, the whole meme of "is it a bug or a feature" is mostly humorous, but it is based on the fact that some behavior is ambiguous, and hard to classify as "bug", "feature", or "something that will be improved with a future enhancement".

We could continue to argue about what category this particular behavior of the torus generator falls into, but I don't think doing so would be productive. It seems that Philo and you believe that it does not qualify as a bug. That's perfectly valid, and I respect your opinions. However, I don't think it's valid for you to claim that it couldn't possibly be a bug. And I stand by my statement that in my opinion it does qualify as a bug, but if and only if the main use case for the generator is to generate LDraw primitives.

Even if it doesn't qualify as a bug, that still leaves the possibility that it is something that will be improved with a future enhancement.