LDraw.org Discussion Forums

Full Version: Train track 'resolution'
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
After I finished 53400, the PF curved track, I started on the PF points (53404 & 53407). As these are going to be big files I wondered if I could reduce the file size. The most obvious way would be to make the steps or sections in the curved rails bigger so as an experiment I changed 53400 from roughly 10LDU sections to 20LDU sections. That took 42% off the combined file sizes of the sub files. I then viewed both versions in LDView and didn't spot a difference:
So what do you think? Going forward, use 10LDU or 20LDU 'resolution' for curved track parts?
Seeing the results I'd favor the 20ldu version (or even coarser?) Don't forget also that even if file size saving is nice, key point is overall triangle number!
I would prefer, if you could upload both version to the forum, that I/we can compare it from all sides.

Here you go, both versions to compare. The main part is the same for both, the difference is in the subfiles.
They kinda go hand in hand though ;-)
The file size reduction is because the number of quads in the rails is cut in half. The number of lines of course has also gone down.
I think, after diving deep into the part, I would vote for using the 20 LDU version. :-)

I don't think the difference is noticeable/relevant in programs doing normal smoothing (like LDView) but it might be noticeable in e.g. 1 on 1 POVRay exports etc.
What would be the next logical resolution?
8 / 16 / 48 / ?

10ldu-part gives a resolution of 512 sections for a full circle
20ldu-part gives a resolution of 256 sections for a full circle

Wouldn't 192 be a better choise?
8 / 16 / 48 / 192
I don't understand what you mean...
Where does 8/16/48 come from? Yes, 192 would be the next number in that sequence and 960 would be next, but I don't see what that means for these parts.
The 10LDU or 20LDU are coming from how the curved part and the sub-parts are constructed, not from how many sections there are in a full circle.
I'm thinking of primitive substitution here. 8 /16 / 48 is our current choises of primitives, low/normal/high resolution.
What would be the next one? very hi-res? 96 or 192? Os something else?

I can see, and understand why 256, or 512, is the best choise here, based on the design of the part.
This part is 1/16th of a full circle. Placed on four sleepers/ties. 4x16=64. 64x4=256 or 64x8=512

Since this part/subpart is made without using primitives, it doesn't matter.
Maybe I got "sidetracked", playing around with the numbers here, trying to understand it. ;-)

But the question is somewhat interesting. How do different software work with primitive substitution?
LDView seams to 'recalculate' rather than 'substitute' primitives.
We use 8/16/48 for dividing circles (low-res, normal, high-res) in our primitives.
Basically I think, we should not adapt this system here. I'm fine the 256/512 result.
BTW: The point mentioned by Roland is interesting. I think, we should check the result, after running both files through POV-Ray and see what happens with 10/20 LDU version, there...

Back from holidays :-)
I've just updated the subfiles for 53400 with the 20LDU versions and at the same time fixed the small issues that were mentioned in the comments.
Back to work on the switches/points now.
It may be bad form to reply to my own post but I'd just like to remind the reviewers that the curved PF track piece needs some more votes. Magnus found a few minor issues that have since been fixed and now it's just sitting there, waiting for a few more votes so it can join its cousin, the straight PF track piece, in the next official release.