LDraw.org Discussion Forums

Full Version: I need a fast and frugal renderer
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
I agree that with you that your system seems powerful enough. I also agree that the initial load time for files isn't one of LDView's strong points. (It is on my list of things to try to improve.) One thing you can do now to improve load time in LDView (at the expense of rendering performance) is to set the "Memory usage" setting in LDView's General tab in Preferences to "Low". This will skip the final step in the model load. (For the OpenGL programmers out there, the final step is display list compile, which takes a little bit of time, and tends to use a lot of memory.)

Unfortunately, it doesn't seem to make a very big impact on load time. On my test computer, Orion's rendition of 10030 loads in about 5.8 seconds with memory usage set to "High", and 5.4 seconds with memory usage set to "Low". Frame rate once loaded has a bigger difference, with 42FPS when set on "High", and 27FPS when set on "Low". Please note that both load times were timed with my stopwatch that only has .2 second accuracy, and both were timed for a reload (F5), since the first load of the file has to load all the parts from disk, while subsequent loads get them from the cache. Since I didn't feel like rebooting my computer between test runs, that's the best timing info I have.
Tore Eriksson Wrote:
-------------------------------------------------------

> The bottom line is, I still need a good
> replacement for L3Lab, absolutely max 50% slower
> when it comes to loading models.

Tore,

I know you're not using a Mac, but I figure you might appreciate some generally applicable background information.

Part of your frustration is that you conflate loading time and drawing time. They really are very different operations, it's just that you apparently don't notice it because of your workflow. In any modern 3D graphics API (having vastly more power than non-hardware-accelerated systems), the structure in which you submit the geometry data is critical to fast drawing. LDraw files are not naturally favorable to that structure and must be massaged quite a bit to produce something which draws reasonably fast. This process elongates loading time, but results in drawing performance improvements of over an order of magnitude. In any graphical editor, the model is redrawn over and over; drawing time is vastly more important than a few seconds of parsing and reformatting. Likewise, any viewer that wants to support drawing the same model more than once must optimize for drawing over loading.

Loading impact can be reduced by amortization and caching. In Bricksmith, the first load of Orion's 10030 takes 5.8 seconds on my three-year-old Mac. The second load (provided you don't quit the program in between) takes 0.06 seconds, simply because I only throw away the 10030 itself, not the individual parts inside it. Even better, using a hardware-accelerated graphical editor to build your model would incur no loading time whatsoever while adding and moving parts, and would only be bound by the drawing fps. In which case, faster drawing wins the day.

Allen
Hi Allen,

One thing I've often wondered is whether or not a 'render friendly' format for the LDraw library wouldn't be useful. For example if you and Travis (as rulers of the two most common rendering tools) could come up with a standard format you could cache the parts library into the new format and add new parts as needed.

Or more precisely, when you run an LDraw viewer/editor the following happens
1) Check to see if LDrawParts.qik exists - if yes, go to 3)
2) Generate LDrawParts.qik with parts in format useful for fast 3d rendering
3) Load model. If it contains any part does not exist in LDrawParts.qik but exists in /ldraw/parts conver and add to LDrawParts.qik.
4) Use preprocessed parts in LDrawParts.qik to render

Of course stage 2) could be ignored and you simply add parts as they appear in models. Or 2) could be voluntary.

This way you wouldn't break the standard format but could have an in-between format. And if you and Travis could come up with a standard a user could even share the file.

Tim
I've actually considered doing something like this but didn't do so for two reasons:
  • It's a fairly involved feature, and requires careful thought. Cached data needs to contain a timestamp, and any parts that are updated in the library need to automatically trigger regeneration of the cached data.
  • LDView's architecture makes it less useful than it otherwise might be (see below).
If you look at the status bar while loading a big model in LDView, you might notice that it has a number of stages: Loading, Calculating Size, Parsing, Compiling.

The Loading stage loads the data from the LDraw files into memory in structures that contain all the data from the files, but that's about it. (It also constructs a tree representing all the files referenced in the model, reusing files that are reused.) Very specifically the data structures at this point are not graphics-specific (and in fact get used directly for my POV exporting). I could create a binary cache of the data at this point, but that's only about 20% of the total load time, so it's not particularly useful.

The Calculating Size stage does basically what it says it does, and wouldn't be aided by caching of the parts.

The Parsing stage transforms the data from the original format into the format I need for my graphics engine, and also performs primitive substitution and curve smoothing. I could create a binary cache of the final processed data, but LDView relies on the original data from the Loading stage for various functions, so I'd need to either create a separate cache for that, or simply still load the original LDraw files for that step, or go through a major rearchitecture of LDView so it didn't rely on that data. All of those options are fairly major, so caching has been put on the back burner.

To make things even more complicated, the results of both the Loading stage and the Parsing stage are different based on what options are selected in LDView. As one example, if you ask for low-res studs, it loads the low-res stud files from disk instead of the normal ones. It doesn't load both, so the data I get is different depending on that setting. Similarly, if you turn on Primitive Substitution, you get different geometry out of the Parsing stage than you get if that feature is disabled. So any caching in LDView would have to take this into account, thus complicating things quite a bit more than they already were.
I forgot the one setting that is likely to speed up loading the most: disable the "Smooth Curves" setting on the Effects tab of Preferences. On the same 10030 model on a different computer, unchecking this box brought the load time from 10 seconds down to 5 seconds (still with memory set to Low).
Thanks for the explanation. This all makes sense.


Tim
Is the load/calc/parse/compile time a problem because the viewer (l3lab or ldview) is being used in polling mode to display work done in a a separate program such as lddp or a text editor?

If so, would it be possible for ldview to keep most of that work from the previous poll and only recompile the actual bits that have changed? Or does it already do this? If ldview could keep the recompile time under a second then it'd make a really nice editor component.
LDView reloads completely when in polling mode. This could be fixed, but would require a lot of work due to the fact that changing settings in LDView can also force it to either reload or reparse. Adding file-changed reload logic into the existing settings-triggered reload logic is a lot of work. Also, I the polling currently only pays attention to the top-level file, and while it would be nice for it to pay attention to all loaded files and only reload the ones that actually changed, that's also a lot of work.
Ah well, one of these days I'll convince you to add an editing mode to ldview.

Is there no easy way (be it meta command, socket, named pipe, or whatever) that an outside program could tell ldview to add, delete, or move just one part in the main model file without starting over from scratch? That would cover the vast majority of the editing operations. If those three ops were fast then ldview would be fine for creating and editing ldraw files.

Have fun,

Don
I've spent a lot less time on LDView in the past year than probably any year since its original release. So changing its focus like that just seems unlikely. It could be done, with probably relatively minor changes to the graphics engine, but making a good editor is a huge task. And with Roland now actively creating a new OpenGL-based cross-platform editor (LDCad), I don't really think there's much point.

Having said that, LDView is GPL, and the latest source is always on sourceforge.net. If someone else wanted to create an editor based on it (or modify it to be an editor), there's nothing stopping them. I'd even try to provide anyone trying to do so a crash course in LDView's overall architecture. It would probably take a fair bit of work to convince me to let the editor functionality become a part of the mainstream LDView, but I wouldn't rule out a separate editor app based on the same source tree for the underlying loading and rendering.
Pages: 1 2 3