Notes for implementing LDraw Part Spec

[elfprince13]

Here are the preliminary fields of the data structure that will be used to store LDraw models in engine.

[KermMartian]

Dug for parts cache. In all seriousness, though, very nicely done, I of course cannot wait for the final product.
_________________

[elfprince13]

you'll notice that there are actually several different caches

one for raw parts data being read from disk and parsed into memory, and one (three actually) for storing vertex buffers for top level rendered objects, to prevent having to recurse down the entire part tree every time the model is rendered, and to allow the entire model, no matter how many poly's, to be rendered in a fixed number of OpenGL calls.
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative

[elfprince13]

Thus far today I have fixed FreeBuild so it asks the OS for the proper directory to write log files too. Real handling of this has only been implemented on OS X so far, but the skeleton is there for the others, and just needs me to actually fill in the code. This mean console.log is now written to ~/Library/Logs/Freebuild/net.cemetech.freebuild.log


I've also begun adding the ability to find + use the system LDraw repository before I bother doing any more work with lex's buffer handling.
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative

[elfprince13]

Triple posting spree ftw.




I should mention that under Windows this comes with the caveat of only being able to select LDraw directories on the same drive that FreeBuild was launched from.
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative

[DShiznit]

Because you don't know how to use windows...

[elfprince13]

[DShiznit]

Well then that's torque's fault now isn't it? That being said, I have no problem with this restriction. The LDraw Library isn't THAT big, I can have it on multiple drives if I want FreeBuild on multiple drives.

[elfprince13]

[elfprince13]

Reading up on the Torque Networking Library, and in particular, the fine details of Ghosting, Tickability, and NetEvents.
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative

[elfprince13]

So as far as I can tell, the lexer and parser for loading LDraw models are ready to go, and I just need to set them up to actually DO something with the data they read.
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative

[elfprince13]

For you-all's edificaton:
http://sfgp.cemetech.net/freebuild/SketchedOutline-LDrawComponents.pdf
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative

[elfprince13]

Double Post, this log shows off a couple clear issues with the parser as it stands right now.

My file loading is having difficulty locating stickered bricks in the s/ subdirectory of parts when they are specified by the full path rather than just the filename.

Secondly, the ~4KB car.dat takes at least a minute to load, whereas the ~300KB blockade_runner.mpd loads almost instantaneously. Presumably this is because the mpd loader attempts to cache things and the normal loader does not. If I then try to load the car a second time, after blockade_runner has loaded, it also loads very quickly, but I get a large number of syntax errors. Presumably this means that once the file is cached, the non-MPD loading mode can find the files there, but is having trouble actually loading them (either due to improper caching, or improper cache-loading).

[elfprince13]

I've implemented the radix trees that will be an integral part of the in-memory cache. Before I continue with that, I need to rework the way the lexer handles an mpd document, because as of right now it caches the whole token stream without executing any of the commands within the file. Non-mpd files appear to be working fine.

[edit]
hextuple post ++
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative

[CyberPrime]

CCCOMBO BREAKER

Anyway, very cool stuff elf. I can't wait to see some in-game renders that look decent

[elfprince13]

[elfprince13]

Since LDraw bricks are not textured in the usual sense of needing images I should be able to do some extreme texture atlasing and cram up to 65k different 4*4 color patches into a single 1024*1024 texture. This should be more than sufficient as the total number of colors that are allowed (by the language specification) at any one time is 512. However, since each file can have its own color definitions that do not scope outside that file, it is important to leave room for models to define their own colors without overriding the default definitions. I don't expect most models to define more than a handful of custom colors, but with this scheme we could have 127 models define the maximum number of colors, and leave the default color table unpolluted.

I will need a few shaders to handle the different material properties, but this number will still be very low.
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative

[TheStorm]

Woo, and with s3tc compression you can make it so that the color map texture doesn't need much vram to use and from what I hear it is rather easy to map the 4*4 patches to the face they need to be on.

A thought I just had for the studs would be to maybe use a tiled texture of it with an alpha layer on the top of the bricks so that you only need the color map texture and the stud texture to handle the entire brick. Though I'm sure you already have already thought this part through, so ignore me if I am totally off base.
_________________

"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live" -Unknown

"If you've done something right no one will know that you've done anything at all" -Futurama

"Have a nice day, or not, the choice is yours." Tom Steiner

<Michael_V> or create a Borg collective and call it The 83+
<Michael_V> Lower your slide cases and prepare to be silent linked. Memory clears are futile.

[elfprince13]

[KermMartian]

Whoa, I had missed a rare post from CyberPrime! Great to hear about these efficiency ideas; efficiency will definitely be excellent for those of our members with weaker computers, now that we're going with the more intensive T3D engine.
_________________