Tore Eriksson Wrote:
-------------------------------------------------------
> What lighting? The parts made by DatShine, or?
e.g. b\3001.dat has only a reference to box.dat, this isn't bad it will be drawn etc. But because it's threaded as a model instead of a part it won't correct for scaling etc in regards to normals. This results in all those bricks being gray instead of e.g. white in the whole city's rendering.
I'm rewriting the file id-er to circumvent this by promoting any files with non (-)1.0 determinants references, but because of rounding errors it decided to promote whole town0-2.ldr to a single part
But with a fuzzy compare it seems to work without adjusting headers.
>
snip
>
> If you mean your editor may have the option to for
> example right-click on a part or a group of parts,
> and you may manually select their state as
> "Standard", "Boxed", "No top studs", "No bottom
> details" - that would be really awesome!
>
I was thinking about special part bin groups and replacement actions on the selection.
> When it comes to your editor demanding the exact
> line "0 !LDRAW_ORG Unofficial_Part" to treat an
> object as a part, I find it a very vulnerable
> approach. It may be better to have a look at how
> Lars solved the issue in L3P 1.4B, as L3P somehow
> handles boxed parts as parts. I don't know if L3P
> regards all files with .DAT extension as parts (I
> don't think so, I'm not sure?) or any file placed
> in the LDraw\Parts path (except sub-parts of
> course!) as parts. That may be a less fragile and
> more future safe approach since the header
> standards constantly change.
>
> /Tore
It all depends what the software in question wants to do with it. l3p and povray wouldn't care because they don't use normals the way e.g. OpenGL needs them, so it's a non issue for those apps.
I need to know what's a part and what not in order to optimize the 3D data speed and memory wise. For example loading the town.ldr in my editor eats 'only' about 400MB of memory but still renders at less then a second.
So depending on the rendering method knowing if something is a part or model is very valuable information (real-time) rendering speed and quality wise.
-------------------------------------------------------
> What lighting? The parts made by DatShine, or?
e.g. b\3001.dat has only a reference to box.dat, this isn't bad it will be drawn etc. But because it's threaded as a model instead of a part it won't correct for scaling etc in regards to normals. This results in all those bricks being gray instead of e.g. white in the whole city's rendering.
I'm rewriting the file id-er to circumvent this by promoting any files with non (-)1.0 determinants references, but because of rounding errors it decided to promote whole town0-2.ldr to a single part
But with a fuzzy compare it seems to work without adjusting headers.>
snip
>
> If you mean your editor may have the option to for
> example right-click on a part or a group of parts,
> and you may manually select their state as
> "Standard", "Boxed", "No top studs", "No bottom
> details" - that would be really awesome!
>
I was thinking about special part bin groups and replacement actions on the selection.
> When it comes to your editor demanding the exact
> line "0 !LDRAW_ORG Unofficial_Part" to treat an
> object as a part, I find it a very vulnerable
> approach. It may be better to have a look at how
> Lars solved the issue in L3P 1.4B, as L3P somehow
> handles boxed parts as parts. I don't know if L3P
> regards all files with .DAT extension as parts (I
> don't think so, I'm not sure?) or any file placed
> in the LDraw\Parts path (except sub-parts of
> course!) as parts. That may be a less fragile and
> more future safe approach since the header
> standards constantly change.
>
> /Tore
It all depends what the software in question wants to do with it. l3p and povray wouldn't care because they don't use normals the way e.g. OpenGL needs them, so it's a non issue for those apps.
I need to know what's a part and what not in order to optimize the 3D data speed and memory wise. For example loading the town.ldr in my editor eats 'only' about 400MB of memory but still renders at less then a second.
So depending on the rendering method knowing if something is a part or model is very valuable information (real-time) rendering speed and quality wise.