Datsville


Datsville
#1
Hi all, I've been playing around with datsville.

But somehow I thought it was bigger, I'm using the version from datsville.googlecode.com.

Anyone has a newer / bigger version?

Also why is everything stuffed in a gigantic MPD (33000 lines!) Not very efficient for use in svn.
Reply
Re: Datsville
#2
Roland Melkert Wrote:
-------------------------------------------------------
> Hi all, I've been playing around with Datsville.
>
> But somehow I thought it was bigger, I'm using the
> version from datsville.googlecode.com.
>
> Anyone has a newer / bigger version?
>
> Also why is everything stuffed in a gigantic MPD
> (33000 lines!) Not very efficient for use in svn.


I'm really glad you brought this subject up. It's still my favourite LDraw subject, even though I once again have taken a long break from the work. This week for example, I've shown LDraw, Datsville, and my 7 seconds animation for four of my friends. It sort of inspired me a little, almost enough to pick up the work again. Let's say I'm very close to a relapse now. Smile

This is my unofficial version of Datsville, from last Christmas. http://dl.dropbox.com/u/15954981/rev038.zip
I think it is the latest, but I haven't checked if there are some half-finished things I was into when I got caught up in other stuff again... What you need to know is that I've replaced lots of parts with boxed versions of dat files (for example B\3001.dat instead of 3001.dat) where it shouldn't make any difference. You'll have to create the folder 'B' in your LDraw\Parts folder, and unpack the content of Boxed_dats...zip into LDraw\Parts\B to make this version of Datsville renderable.

I would really need some helping hands, as I felt I'm losing my inspiration and along with that my creativity. There has been a lot of grunt work, just filling areas with grass and sidewalks. Anyone who wants to join this project will get a lot of power and quite free hands to add models and make changes in the layout if needed. I still wish to have the final veto, but I may hand that over too if somebody with the right energy and visions wishes to take over.

http://dl.dropbox.com/u/15954981/rev038.zip

/Tore
Reply
Re: Datsville
#3
Wow thanks for this version.

Thanks for the offer but I'm not really a modeller, but always admired datsville for it's bigness Smile

I also like to use it to test my LDraw software, this version unveiled some problems with my current renderer in regards to 'boxed' parts (it doesn't recognize them as being parts, and messes up lighting some how.).

Those boxed parts are they hand generated? or do you use some software for them. Ether way I think general support for them would improve if you added at least "0 !LDRAW_ORG Unofficial_Part" as a first line.

Anyhow it's a very clever idea to eliminate unneeded geometry, I'm getting ~1.5 fps out of town.ldr Smile

Maybe I could help the project by adding special support for e.g. boxed parts to my editor, any thoughts on that?
Reply
Re: Datsville
#4
Roland Melkert Wrote:
-------------------------------------------------------
> Wow thanks for this version.

Thank you for showing some interest in it. However, when I checked it after zipping it and posting the link here, I noticed that there is a couple of references to non-existing parts or models. I have to check that up tonight.

> I also like to use it to test my LDraw software,
> this version unveiled some problems with my
> current renderer in regards to 'boxed' parts (it
> doesn't recognize them as being parts, and messes
> up lighting some how.).

What lighting? The parts made by DatShine, or?

> Those boxed parts are they hand generated?

Some are, some are not. It depends on the part's complexity. Most Basic bricks, plates, and tiles are made by a very simply DOS program I rushed together.

> or do you use some software for them.

Of course, I use LDraw Boxer to automatically determine where parts can be replaced by boxes. But I guess that wasn't the question.

> Ether way I think general support for them would improve if you
> added at least "0 !LDRAW_ORG Unofficial_Part" as
> a first line.

Hmm, I think you're right. As I have experienced almost no general support whatsoever for my ideas and my objections, and that those standards constantly change, I haven't even cared about what currently is required as long as it works for the softwares I use.

> Anyhow it's a very clever idea to eliminate
> unneeded geometry, I'm getting ~1.5 fps out of
> town.ldr Smile

Thank you! Big Grin

> Maybe I could help the project by adding special
> support for e.g. boxed parts to my editor, any
> thoughts on that?

That would be really great of course! Normally, it shouldn't be necessary to add any special support as I tried to find a system that just works without any manual hands-on.

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!

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
Reply
Re: Datsville
#5
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 Smile 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.
Reply
Re: Datsville
#6
Roland Melkert Wrote:
-------------------------------------------------------
>
> 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.

This is way beyond my skills, so I just have to trust you on that. But I know that L3P needs to know whether it deals with a part or a model, because it produces seams between parts but not between models. And it's capable of identifying a part even without the information from the header.

> 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.

That's fantastic! I really want to keep my library of boxed DATs as small as possible, but this makes it so interesting that I might let it explode in size (and thus, the POV output files generated by L3P...) by adding those so far not needed extra lines.

Besides the file size factor, I've been hesitating to use the Name !LDRAW_ORG in vain for my own private, unofiffcial files. My understanding of "0 !LDRAW_ORG Unofficial_Part" is:
* Property of LDraw.org. You may use it under this and that Licence Agreement if you agree with this and that.
* This file meets header standards and all other silly specs the LSC have come up with. At least it did when released.
* This part is in the Parts Tracker, waiting to be part of the Official LDraw Parts Library.
* In other words: Don't use this line at home! It is reserved for a few chosen Admins trusted with it.
No, that's not really my understanding of it. Smile But it's sure what it's signaling.

And I'm prepared to suppress those feeling if needed for the good sake, if necessary to make your editor support boxed parts.

> 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.

And, like I said, if the main file resides somewhere in LDraw\Parts, that information itself should be sufficient(?) to determine that you're dealing with a part.

/Tore
Reply
Re: Datsville
#7
Tore Eriksson Wrote:
-------------------------------------------------------
> I really want to keep my library
> of boxed DATs as small as possible, but this makes
> it so interesting that I might let it explode in
> size (and thus, the POV output files generated by
> L3P...) by adding those so far not needed extra
> lines.

I've got it working now without the need for header information, but it's still guessing and so it can guess wrong, like for example the town0-1.ldr has this line:

1 7 540 0 -800 0 0 0.50 0 0.50 0 -0.50 0 0 baihous1.ldr

The whole house is scaled down (to datsville scale I guess?). This will cause my 'improved' guessing code to handle the whole town0-1.ldr as a single part. But it can be corrected by fixing the header of town0-1.ldr only instead of all the boxed parts.

>
> Besides the file size factor, I've been hesitating
> to use the Name !LDRAW_ORG in vain for my own
> private, unofiffcial files. My understanding of "0
> !LDRAW_ORG Unofficial_Part" is:
> * Property of LDraw.org. You may use it under this
> and that Licence Agreement if you agree with this
> and that.
> * This file meets header standards and all other
> silly specs the LSC have come up with. At least it
> did when released.
> * This part is in the Parts Tracker, waiting to be
> part of the Official LDraw Parts Library.
> * In other words: Don't use this line at home! It
> is reserved for a few chosen Admins trusted with
> it.
> No, that's not really my understanding of it. Smile
> But it's sure what it's signaling.
>

You right about the !LDRAW_ORG it implies it's part of the library official or not. But as far I can find there is no other way of marking the nature of a ldraw file. I think I'm going to bring this up in the LSC.

> And, like I said, if the main file resides
> somewhere in LDraw\Parts, that information itself
> should be sufficient(?) to determine that you're
> dealing with a part.
>

You are right but there are exceptions for example shortcuts threading them as parts will double used resources for the referenced 'real' part, and don't get me started about the fixed color parts, they would plunder VGA resources like locus.
> /Tore
Reply
Re: Datsville
#10
Roland Melkert Wrote:
>
> I've got it working now without the need for
> header information, but it's still guessing and so
> it can guess wrong, like for example the
> town0-1.ldr has this line:
>
> 1 7 540 0 -800 0 0 0.50 0 0.50 0 -0.50 0 0
> baihous1.ldr
>
> The whole house is scaled down (to datsville scale
> I guess?). This will cause my 'improved' guessing
> code to handle the whole town0-1.ldr as a single
> part. But it can be corrected by fixing the header
> of town0-1.ldr only instead of all the boxed
> parts.
>

For a human, the line:
0 Unofficial Datsville Town Sub-Model
says it all, but I understand it's a bit harder to make software with logic fuzzy enough to understand it.

If a header line contains the string "official" (disregard upper/lowercase), that line probably a part/model/primitive identifier.
- If one header line contains both "official" and "model" (disregard upper/lowercase), it's a model.
- If one header line contains both "official" and "part" - but not "sub-part"! (disregard upper/lowercase), it's a part.
If a file contains type 1 references to .LDR files, it's a model.
If a file contains references to parts, it's most likely a model.
If a file contains several line type 2 - 5 and references to primitives, it's likely a part.

But I also understand that if a program has to evaluate a lot of part files with this fuzzy logic, it takes more processing than it should have had to. I think I'll soon get back with a suggestion of a better alternative to that !LDraw_org meta-statement...

/Tore
(I've changed my mind about "If a file is located in the Parts folder...", since there are lots of shortcuts, like mc with rider, that have to be treated as models, not parts.)
Reply
Re: Datsville
#11
Most of those assembly Parts folder files, like the motorcycle+rider are anachronistic and probably would not be included if they were suggested today. We did reject the inclusion of the minifig-scale destroyer droid, IIRC. Backward compatibilty, and all that, means we can't really delete them. I suppose they could be moved to Models, as "usage examples", like car.dat and pyramid.dat.

So, I'm not sure you should define any algorithm that allows models to exist in the Parts folder.

Personally, I'm very worried about the proposed fuzzy logic. It's that kind of vague header formatting that convinced us (well me at least) to formalise the Parts file header as you see it today. This means that the format can be programmatically checked - and other tools can rely on the defined semantics.

Something like "0 !PRIVATE Unofficial_Set", would allow us, in the future to start issuing LDraw.org versions of models, using "0 !LDRAW_ORG Unofficial_Set" during review and "0 !LDRAW_ORG Official_Set" upon release.
Chris (LDraw Parts Library Admin)
Reply
Shortcuts in the Parts Folder (was: Datsville)
#12
Chris Dee Wrote:
-------------------------------------------------------
> Most of those assembly Parts folder files, like
> the motorcycle+rider are anachronistic and
> probably would not be included if they were
> suggested today.

A great fortune they did make it there in time then!

> We did reject the inclusion of
> the minifig-scale destroyer droid, IIRC.

That's really bad. It would be very handy to have in the Parts folder where it belongs..

> Backward compatibilty, and all that, means we
> can't really delete them.

That is in deed very good news!

> I suppose they could be moved to
> Models, as "usage examples", like car.dat and
> pyramid.dat.

I suppose not!

> So, I'm not sure you should define any algorithm
> that allows models to exist in the Parts folder.

Shortcuts could techically be called "models", but from my POV they are much closer to be treated as parts than models, even though they really are neither.

> Personally, I'm very worried about the proposed
> fuzzy logic. It's that kind of vague header
> formatting that convinced us (well me at least) to
> formalise the Parts file header as you see it
> today. This means that the format can be
> programmatically checked - and other tools can
> rely on the defined semantics.

I think you worry too much. Smile Let's keep those two things separate:
A. Shortcuts in the Parts folder are already formally defined
0 !LDRAW_ORG Shortcut UPDATE 2010-02 (30187c03.dat)
From the software's POV, it should be treated as a model.
But as an LDraw user, I DON'T want it on my own private workspace, ie the Models folder. No way!
B. I made the mistake to have no header at all in some of my boxed parts. This has been no problems with the software I've used so far, but Roland has made me aware that it may cause problems in some cases, like his new editor.

How do we address issue B? (Issue A is a non-issue IMO) The bad, really bad way would be a new, over-formalized Standard that you force us poor users to obey, or else we will encounter endless warnings and errors. Of course it will render all previously made models illegal, like DAT-Header now signals 'Hold' for all parts ending with the previouly compulsary "0" line. (Oh, stupidivity of stupidivities!) Now, where was I? I don't mind a new syntax, like "0 !PRIVATE Part", although I find it too easy to misunderstand for those who happen to have that kind of humour.

But I get very much more worried about the opposite ditch. Leaning too much on defined semantics, blaming the ignorant users for all syntax errors. Backwards compability should IMO also mean that software recognize parts and models made 5 or 10 years ago, without spitting out needless and annoying warnings and errors. They should accept and understand statements like:
0 Un-official Part
0 Un-official LDraw Primitive
0 Unofficial Shortcut
0 Unofficial Classic Space Model
0 Unofficial Moonbase Vehicle model
, regardless what standard may be set - or later on altered again.

Instead of "0 !PRIVATE" as a complement to "0 !LDRAW_ORG", I would suggest either "0 !LDRAW" or maybe "0 !INFO". But maybe there's an even better name?

> Something like "0 !PRIVATE Unofficial_Set", would
> allow us, in the future to start issuing LDraw.org
> versions of models, using "0 !LDRAW_ORG
> Unofficial_Set" during review and "0 !LDRAW_ORG
> Official_Set" upon release.

1. What motivates that unnatural underscore in Official_Set? In LDRAW_ORG, I can understand it, but not to separate normal words from each_other. That underscore is a heavily potential source of errors. It makes it (slightly) harder to write and much harder to remember to write as it's certainly not the normal way to write. And also, it's a little harder for the programmer to extract relevant information like is it a model, part, primitive, assembly or a shortcut.

2. Isn't a set still a model, or is there a difference I have overlooked?

(Hmm, let me see if I got it right about to start issuing LDraw.org versions of models. First, it's an LDraw.org unofficial official TLG set model that after after reviewing becomes an LDraw.org official official TLG set model. Right? Oh, where are my Aspirine pills...?) Smile

/Tore
Reply
Re: Shortcuts in the Parts Folder (was: Datsville)
#13
Tore Eriksson Wrote:
-------------------------------------------------------
> But as an LDraw user, I DON'T want it on my own
> private workspace, ie the Models folder. No way!
> B. I made the mistake to have no header at all in
> some of my boxed parts. This has been no problems
> with the software I've used so far, but Roland has
> made me aware that it may cause problems in some
> cases, like his new editor.
>
Current version handles them fine without a header, only thing is there's a chance on 'glitches' cause it's guessing (aka applying fuzzy logic).

I'm not expecting (or demanding) users to change stuff in order to use my software, it might only hurt render quality or prevent them from (easily) editing a particular model.

> How do we address issue B? (Issue A is a non-issue
> IMO) The bad, really bad way would be a new,
> over-formalized Standard that you force us poor
> users to obey, or else we will encounter endless
> warnings and errors. Of course it will render all
> previously made models illegal, like DAT-Header
> now signals 'Hold' for all parts ending with the
> previouly compulsary "0" line. (Oh, stupidivity of
> stupidivities!) Now, where was I? I don't mind a
> new syntax, like "0 !PRIVATE Part", although I
> find it too easy to misunderstand for those who
> happen to have that kind of humour.
>

Personally I use all information in the headers as 'nice to have', if missing my software won't add stuff or make changes unasked. But like said it will hurt rendering and or functionality when it can't be parsed and identified correctly. that's where the power of a good standard comes in.


> But I get very much more worried about the
> opposite ditch. Leaning too much on defined
> semantics, blaming the ignorant users for all
> syntax errors. Backwards compability should IMO
> also mean that software recognize parts and models
> made 5 or 10 years ago, without spitting out
> needless and annoying warnings and errors. They
> should accept and understand statements like:
> 0 Un-official Part
> 0 Un-official LDraw Primitive
> 0 Unofficial Shortcut
> 0 Unofficial Classic Space Model
> 0 Unofficial Moonbase Vehicle model
> , regardless what standard may be set - or later
> on altered again.
>
You are right there should always be a 'fallback' but users can't expect all software to handle all documents flawlessly, especially if the documents are that old and don't 'try to help' the parser.

> Instead of "0 !PRIVATE" as a complement to "0
> !LDRAW_ORG", I would suggest either "0 !LDRAW" or
> maybe "0 !INFO". But maybe there's an even better
> name?
>

I will take this up in the LSC soon, maybe a generic 'what's the nature of this document' meta would help which programs can scan for the term "model" or "part". Or a simular meta with a set of static keywords to choose from.

> > Something like "0 !PRIVATE Unofficial_Set",
> would
> > allow us, in the future to start issuing
> LDraw.org
> > versions of models, using "0 !LDRAW_ORG
> > Unofficial_Set" during review and "0 !LDRAW_ORG
> > Official_Set" upon release.
>
> 1. What motivates that unnatural underscore in
> Official_Set? In LDRAW_ORG, I can understand it,
> but not to separate normal words from each_other.
> That underscore is a heavily potential source of
> errors. It makes it (slightly) harder to write and
> much harder to remember to write as it's certainly
> not the normal way to write. And also, it's a
> little harder for the programmer to extract
> relevant information like is it a model, part,
> primitive, assembly or a shortcut.
>
It's a parser thing, it so the grammar can be dissected without worrying about multiple words in a single 'token'. After it's read the program can split it on the _ and handle it from there (sub parsing the intended goal). An alternative would be using " " around the goal e.g. 0 !PRIVATE "datsville model" or by making it a single variable meta (everything after !PRIVATE is a single value no further dissection needed in order to get the 'goal text' part of the string.)


> 2. Isn't a set still a model, or is there a
> difference I have overlooked?
>
> (Hmm, let me see if I got it right about to start
> issuing LDraw.org versions of models. First, it's
> an LDraw.org unofficial official TLG set model
> that after after reviewing becomes an LDraw.org
> official official TLG set model. Right? Oh, where
> are my Aspirine pills...?) Smile
>

Smile I think the 'official' 'unofficial' keywords only apply to it being in the related library version.
Reply
Re: Shortcuts in the Parts Folder (was: Datsville)
#14
I only used the "Unofficial_" for alignment with existing Part/Subpart/Primitive/Shortcut terminology, under the (maybe false) premise that LDraw.org might like to issue "Official" versions of sets - that have gone through some form of review - as part of the library. I switched from "Model" to "Set" deliberately, as the distributed package already has a Models folder which I suspect many users use as a kind of working area. By using "Set" we could have a "Set" folder alongside Parts.

I think my personal conceptual defintion of "Shortcut" is much more narrow. It is merely a representation of something as delivered already assembled, by LEGO, rather than something that needs to be built be a user.
Chris (LDraw Parts Library Admin)
Reply
Re: Shortcuts in the Parts Folder (was: Datsville)
#16
Chris Dee Wrote:
-------------------------------------------------------
> I think my personal conceptual defintion of
> "Shortcut" is much more narrow. It is merely a
> representation of something as delivered already
> assembled, by LEGO, rather than something that
> needs to be built be a user.

Oh, that's what I thought was Assembly.

(But OTOH, I have my strong opinion that a Classic window + glass pane is a true "part", while a window frame or a glass pane is either a sub-part or a broken part. Smile )
Reply
Re: Datsville
#15
Roland Melkert Wrote:
-------------------------------------------------------

> I've got it working now without the need for
> header information, but it's still guessing and so
> it can guess wrong, like for example the
> town0-1.ldr has this line:
>
> 1 7 540 0 -800 0 0 0.50 0 0.50 0 -0.50 0 0 baihous1.ldr
>
> The whole house is scaled down (to datsville scale
> I guess?). This will cause my 'improved' guessing
> code to handle the whole town0-1.ldr as a single
> part. But it can be corrected by fixing the header
> of town0-1.ldr only instead of all the boxed
> parts.

I didn't take the decision to scale down Anders' house, but as insane as that idea is, I think it's better than not scaling it down.
IRL, his home is smaller than my mother's house, portrayed in btehous1.ldr. But he built it in a totally different scale, so it would look more than twice as big if using the same scale.

As much as I appreciate your fuzzy logic approach before hard-boiled stick-to-the-protocol attitude, I wouldn't recommend guessing that it's a part becuse it contains scaled-down objects.
If you like to build a mixed model with standard LEGO parts and LEGO Modulex together, the Modulex section shall be scaled down by the factor 0.625.
1 7 0 0 0 1 0 0 0 1 0 0 0 1 Lego_model.ldr
1 7 40 -72 100 1 0 0 0 1 0 0 0 1 Modulex_model.ldr
0

Also there can be a comical, commonly used basic cartoonic animation effect in stretching and shrinking objects.
From my scene model "Plasteroid Team, Fri May 13th 2011" - http://news.lugnet.com/cad/dat/models/?n=2292
0 // 3 x "Spiffcraft 1" by Dan Jassim
0 // The first Spiff with the Artificial Gravity Device
0 // not perfectly calibrated... Smile
1 4 -240 -32 -50 1.1 0 0 0 0.6 0 0 0 1.1 spiff01.ldr
1 1 0 -78 -48 0.996 0.087 0 -0.087 0.996 0 0 0 1 spiff01.ldr
1 14 240 -98 -50 0.927 0 -0.375 0 1 0 0.375 0 0.927 spiff01.ldr
0

See result in this pic: http://dl.dropbox.com/u/15954981/minifigs.jpg
(On second thought, I guess they must have by mistake left all three Artificial Gravity Devices in the red Spiff-craft.)

Or: What minifigs do when we look away: http://dl.dropbox.com/u/15954981/playrom3.jpg Smile

(I also used a scaled up B\3005.dat's to build a complete house wall in my heavily simplified versions of the buildings in Datsville Lite. But after purchasing a more powerful PC and finally surrendered to Win7, I trashed the Lite version as it took so much more time to produce than the real version.)

The bottom line is that scaled objects may for various reasons appear not only in parts.
Reply
Re: Datsville
#17
Tore Eriksson Wrote:
-------------------------------------------------------
> As much as I appreciate your fuzzy logic approach
> before hard-boiled stick-to-the-protocol attitude,
> I wouldn't recommend guessing that it's a part
> becuse it contains scaled-down objects.

You might be right, this is why we need a new meta, but for now it's a good standard fallback mechanism I think.

I might add options to control the behavior (no header info -> assume model / fuzzy logic / ask) or by giving the user the possibility to define locations from which to assume everything is a model or a manual 'this is a model' override within the editor.

> If you like to build a mixed model with standard
> LEGO parts and LEGO Modulex together, the Modulex
> section shall be scaled down by the factor 0.625.
> 1 7 0 0 0 1 0 0 0 1 0 0 0 1 Lego_model.ldr
> 1 7 40 -72 100 1 0 0 0 1 0 0 0 1
> Modulex_model.ldr
> 0
>

I have no idea what Modulex is, but I setup my editor with 'real world projects' in mind, so current version wont allow manual matrix adjurations and assumes rotation only usage in models. But it won't stop you from editing the files in notepad, it will affect rendering quality though.

> Also there can be a comical, commonly used basic
> cartoonic animation effect in stretching and
> shrinking objects.
> From my scene model "Plasteroid Team, Fri May 13th
> 2011" -
> http://news.lugnet.com/cad/dat/models/?n=2292
> 0 // 3 x "Spiffcraft 1" by Dan Jassim
> 0 // The first Spiff with the Artificial Gravity
> Device
> 0 // not perfectly calibrated... Smile
> 1 4 -240 -32 -50 1.1 0 0 0 0.6 0 0 0 1.1
> spiff01.ldr
> 1 1 0 -78 -48 0.996 0.087 0 -0.087 0.996 0 0
> 0 1 spiff01.ldr
> 1 14 240 -98 -50 0.927 0 -0.375 0 1 0 0.375 0
> 0.927 spiff01.ldr
> 0
>
> See result in this pic:
> http://dl.dropbox.com/u/15954981/minifigs.jpg
> (On second thought, I guess they must have by
> mistake left all three Artificial Gravity Devices
> in the red Spiff-craft.)
>
> Or: What minifigs do when we look away:
> http://dl.dropbox.com/u/15954981/playrom3.jpg Smile
>

Those are fun Smile

> (I also used a scaled up B\3005.dat's to build a
> complete house wall in my heavily simplified
> versions of the buildings in Datsville Lite. But
> after purchasing a more powerful PC and finally
> surrendered to Win7, I trashed the Lite version as
> it took so much more time to produce than the real
> version.)
>
> The bottom line is that scaled objects may for
> various reasons appear not only in parts.

Nothing stop you from doing so (especially with the extra header info), but again it will degrade render quality.
Reply
Modulex (Was: Datsville)
#19
Roland Melkert Wrote:
-------------------------------------------------------
> Tore Eriksson Wrote:
> --------------------------------------------------
> > If you like to build a mixed model with
> standard
> > LEGO parts and LEGO Modulex together, the
> Modulex
> > section shall be scaled down by the factor
> 0.625.
> > 1 7 0 0 0 1 0 0 0 1 0 0 0 1 Lego_model.ldr
> > 1 7 40 -72 100 1 0 0 0 1 0 0 0 1
> > Modulex_model.ldr
> > 0
> >
>
> I have no idea what Modulex is, but I setup my
> editor with 'real world projects' in mind, so
> current version wont allow manual matrix
> adjurations and assumes rotation only usage in
> models. But it won't stop you from editing the
> files in notepad, it will affect rendering quality
> though.

I see absolutely no reason why notepad should affect rendering quality, except for the kind of embarrassing human mistakes I just made by using copy+paste and forgetting to edit. Smile
> > 1 7 40 -72 100 1 0 0 0 1 0 0 0 1 Modulex_model.ldr
should of course be:
1 7 40 -72 100 0.625 0 0 0 0.625 0 0 0 0.625 Modulex_model.ldr

A few Modulex links:
http://lego.wikia.com/wiki/Modulex
http://www.peeron.com/inv/catpic/save/824127118
http://www.bricklink.com/catalogList.asp?q=modulex
http://homepage.ntlworld.com/chris.w.dee/Modulex/
http://news.lugnet.com/cad/?n=17385


/Tore
Reply
Re: Datsville
#18
Roland Melkert Wrote:
-------------------------------------------------------
> For example loading the town.ldr in my editor eats
> 'only' about 400MB of memory but still renders at
> less then a second.

Once again, that's unbelievably impressive! If I could make your editor work on my PC, I guess I could finally delete L3Lab.

Could you do some benchmarking on your PC? Just to compare our systems and maybe be able to estimate the time your editor would take to render town-ldr on my PC.
Town.ldr renders at 63.2 seconds in LDView, and 4.634 seconds in L3Lab on my PC. (That's the reason why I have been so utterly upset about using LDraw colors that L3Lab can't handle...)
What's the score for your PC on those two programs rendering town.ldr?

Here's the version of L3Lab I use, in case you don't have it: http://dl.dropbox.com/u/15954981/L3Lab.exe

Thanks in advance,
/Tore
Reply
Re: Datsville
#20
Tore Eriksson Wrote:
-------------------------------------------------------
> Could you do some benchmarking on your PC? Just to
> compare our systems and maybe be able to estimate
> the time your editor would take to render town-ldr
> on my PC.
> Town.ldr renders at 63.2 seconds in LDView, and
> 4.634 seconds in L3Lab on my PC. (That's the
> reason why I have been so utterly upset about
> using LDraw colors that L3Lab can't handle...)
> What's the score for your PC on those two programs
> rendering town.ldr?
>
> Here's the version of L3Lab I use, in case you
> don't have it:
> http://dl.dropbox.com/u/15954981/L3Lab.exe
>
> Thanks in advance,
> /Tore

LDView seems to be slower then my editor while rotating but it does more eye candy (for some reason it doesn't display render speed on my system), but L3Lab reports ~9 seconds for rendering when the whole city is in view (had to figure out how to zoom first), so your system might even be faster. It basically comes down to your VGA card being somewhat recent (I have a Radeon 3870 512MB which is 'old' they say Smile )

Anyhow you are welcome to join the group of testers I send alpha versions to, as asked in this thread:

http://forums.ldraw.org/showthread.php?tid=173,173

I'm hoping to fix a bug/issue this weekend in order to release the 2nd test version, next week / end of the month.
Reply
Re: Datsville
#21
Roland Melkert Wrote:
-------------------------------------------------------
> LDView seems to be slower then my editor while
> rotating but it does more eye candy

Eye candy is a good thing - if it is possible to deselect with speed to gain.

> It basically comes down to
> your VGA card being somewhat recent (I have a
> Radeon 3870 512MB which is 'old' they say Smile )

Not really when it comes to L3Lab, and probably not with LDView either(?) I know L3Lab only uses CPU power, and I don't know about LDView, but I think it's the same thing there. No 3D acceleration from the VGA card.

> Anyhow you are welcome to join the group of
> testers I send alpha versions to, as asked in this
> thread:
>
> http://forums.ldraw.org/showthread.php?tid=173,173

Done!
Reply
Re: Datsville
#22
Tore Eriksson Wrote:
-------------------------------------------------------
> Roland Melkert Wrote:
> --------------------------------------------------
> -----
> > LDView seems to be slower then my editor while
> > rotating but it does more eye candy
>
> Eye candy is a good thing - if it is possible to
> deselect with speed to gain.
>
> > It basically comes down to
> > your VGA card being somewhat recent (I have a
> > Radeon 3870 512MB which is 'old' they say Smile )
>
> Not really when it comes to L3Lab, and probably
> not with LDView either(?) I know L3Lab only uses
> CPU power, and I don't know about LDView, but I
> think it's the same thing there. No 3D
> acceleration from the VGA card.
>

LDView should use VGA acceleration unless it isn't available, if that's the case I'm afraid my editor won't do much better. But the model being that big it could even be 'slow' with acceleration, I kinda assumed the 60+ seconds you mentioned is including loading time though.

> > Anyhow you are welcome to join the group of
> > testers I send alpha versions to, as asked in
> this
> > thread:
> >
> > http://forums.ldraw.org/showthread.php?tid=173,173
>
> Done!

I'll contact you when I have a new test version ready (need to fix a problem concerning relative references first.)
Reply
Re: Datsville
#23
Roland Melkert Wrote:
> LDView seems to be slower then my editor while
> rotating but it does more eye candy (for some
> reason it doesn't display render speed on my
> system),

In LDView's "General" preferences tab is a "Show frame rate" check box. If you check that, you should get an FPS display, but only while the model is spinning. Note that for a model as big as DATSVille, drawing edge lines (and particularly conditional edge lines) will slow things down dramatically.
Reply
Re: Datsville
#24
Travis Cobbs Wrote:
-------------------------------------------------------
> Roland Melkert Wrote:
> > LDView seems to be slower then my editor while
> > rotating but it does more eye candy (for some
> > reason it doesn't display render speed on my
> > system),
>
> In LDView's "General" preferences tab is a "Show
> frame rate" check box. If you check that, you
> should get an FPS display, but only while the
> model is spinning.

that's enabled, but it still only displays the fps occasionally. Sometimes it pops up after you click one of the buttons (e.g lighting on/off), but most of the time it just wont ever display during rotating. I believe I reported that issue to you a couple of years ago, but you couldn't reproduce.


> Note that for a model as big as
> DATSVille, drawing edge lines (and particularly
> conditional edge lines) will slow things down
> dramatically.

I'm using the excellent shader approach Alex Tyler posted last year on lugnet, so it isn't that much of an impact on a decent card. But one thing I added as a result of rendering datsville is 'distance based edges on/off' in order to prevent the whole scene going 'gray' from the faraway edges, I'm also doing some very rudimentary frustum culling.
Reply
Re: Datsville
#25
Roland Melkert Wrote:
-------------------------------------------------------
> ... one thing I
> added as a result of rendering datsville is
> 'distance based edges on/off' in order to prevent
> the whole scene going 'gray' from the faraway
> edges,

I have to say, that's a really brilliant idea.

/Tore
Reply
Datsville Rev039 - Micro Update
#8
The new revision of my unofficial Datsville is at:
http://cid-7183b586c107b55b.skydrive.liv.../Datsville

* Fixed minor problems with minifig arms and a misplaced BFC statement
* Updated MovedTo parts with parts from LDraw.org 2011-01 Parts Update

/Tore
Reply
Re: Datsville Rev039 - Micro Update
#9
Tore Eriksson Wrote:
-------------------------------------------------------
> The new revision of my unofficial Datsville is
> at:
> http://cid-7183b586c107b55b.skydrive.live.com/brow
> se.aspx/.Public/Datsville
>
> * Fixed minor problems with minifig arms and a
> misplaced BFC statement
> * Updated MovedTo parts with parts from LDraw.org
> 2011-01 Parts Update
>
> /Tore
Thanks I'll play with it tomorrow, in the mean time here are some screen caps from the current output in my editor.

Full town
Zoom in on shell station

I'm still playing with things like 'when not to render edges anymore (cause it becomes a gray mass in the distance that way). But I'm pretty content with it. Thanks for helping me improve my editor by supplying this insane model Wink
Reply
Re: Datsville
#26
Note that a lot of activity on my part occurred in early 2012 at https://code.google.com/p/datsville/.
Reply
Re: Datsville
#27
171.000 parts, very cool.

It certainly bring my graphics card to it's knees, it only manages about 1FPS using my LDCad.

Seems much has changed in the last couple of years.

I'm also glad it's not a single mpd anymore.
Reply
Re: Datsville
#28
Unfortunately I don't have enough RAM to render it in POVray. So I'm kind of stuck until I get a new computer. Wink
Reply
Re: Datsville
#29
My development system has 16GB, so if you have the povray script online somewhere I'm willing to give it a try using the 64bit povray 3.7 RC (3.6 is way to slow using only a single thread).
Reply
Re: Datsville
#30
Note that it actually is impossible to render all of Datville with Pov on 32 bit machines since you run up on the max RAM limit
Reply
Re: Datsville
#31
Yes, Actually needing more then ~2GB memory in a single program is just about the only good reason to use a 64 bit version of a program (on windows).
Reply
Re: Datsville
#37
Most programs also perform 10%-15% faster with a simple 64-bit recompile, at the expense of using somewhat more memory to perform any given task. So big single-program memory space definitely isn't the only reason to have 64-bit versions of programs. I haven't tested POV's performance, but I have tested LDView, and in CPU-bound operations, 64-bit LDView is measurably faster than 32-bit LDView. (In LDView, you generally have to enable conditional lines on a large model in order to see this difference, since most of its geometry drawing isn't limited by the CPU, but by the graphics card.)
Reply
Re: Datsville
#38
I wrote 'just about' Smile

Taking in account the affords it take to make a 64bit version of existing (older) software it just not always worth the effort to create a 64bit version just for the sake of having it.
Reply
Re: Datsville
#43
It's true that your "just about" makes your statement true when taken literally. However, I would maintain that the implied meaning of what you said varies significantly from the literal truth of what you said. It's similar (although to a far lesser extent) to saying that just about the only thing a car is good for is protecting you from lightning strikes during a thunderstorm. In the case of LDView, the main gain you get when running the 64-bit version under Windows is the increased performance, not the larger memory space.

Very few LDraw models are large enough to cause 32-bit LDView to crash due to using more than 3.5GB of memory. (In Windows, a 32-bit program can be compiled to use roughly 3.5GB of memory. If the program is run on a 64-bit copy of Windows, it automatically gets this extra space above 2GB if the option was enabled during compilation. If the program is running on a 32-bit copy of Windows, this only happens if Windows itself is configured to allow it.)

On a side note (not meant to add further disagreement to your statement, but to hopefully add useful information), I have discovered after porting multiple programs to 64 bits that doing so often uncovers previously unknown intermittent bugs (things like uninitialized variables and off-by-one array overflows). Where the 32 bit version might almost never behave wrong due to a given bug, the 64 bit version might always crash, or very frequently crash. So porting a program to run both in 32 bits and 64 bits can in fact improve the overall quality of the program.
Reply
Re: Datsville
#45
You are right, I was just thinking at user level.

While making the 64bit Linux version of LDCad, most problems I had were due to G++ being much more strict then the (old) mingw version, which indeed generated more warnings. Haven't really tested speed differences though, have to build a 64 bit Windows version for that someday (So i can run both in the same environment).

Memory wise 32bit is indeed more then enough for LDraw, datsville for example uses about 500MB in LDCad. But the model as a whole is to slow to edit, but you can double click on any of the submodels and edit those at full speed. And switch back to inspect the overall changes when needed.
Reply
Re: Datsville
#33
Wow, that's good to know!
Reply
Re: Datsville
#35
Yeah, I figured that out a while back when I rendered a small animation using only a piece on Datsville. Even then I had to reduce the settings to allow the thing to process.
Reply
Re: Datsville
#32
Thanks!

If you could render this file at a large resolution that would be great.

http://www.mediafire.com/?z2w8duk4bxma27o

The actual render doesn't take that long. It's the parsing that seems to go forever.


Mike

[edit]

The script depends on LightsysIV which you can get here:

http://www.ignorancia.org/en/index.php?page=Lightsys
Reply
Re: Datsville
#34
I had to turn on the swap file Smile it seems to need about 32GB

Parsing takes forever indeed, the result might be a bit disappointing though:

[Image: datsville.png]

Seems you need to tweak your camera settings (correct for LDraw neg Y axis etc)

Or I'm I doing something wrong?
Reply
Re: Datsville
#36
Ooops!

Try opening datsville.pov and changing

#include "ldr_wrapper_showcase_1.4.inc"

to

#include "ldr_wrapper_1.4.inc"
Reply
Re: Datsville
#39
I'll try again later tonight.

I have to dig up an old sata HDD first, because I don't like running a swap file on my SSD.
Reply
Re: Datsville
#40
Michael Horvath Wrote:Try opening datsville.pov and changing

#include "ldr_wrapper_showcase_1.4.inc"

to

#include "ldr_wrapper_1.4.inc"

Something is wrong, using that it only needs 30 secs to render and doesn't look very HQ at all. Also the camera seems wrong povray complains:

Parse Warning: Camera vectors are not perpendicular. Making look_at the last statement may help.

And it's using ortho mode.
Reply
Re: Datsville
#41
Yes, it's not supposed to look realistic. I'm using it as a map/guide and therefore quality settings aren't important, but the orthographic perspective is.
Reply
Re: Datsville
#42
I forgot to incl the rendering.

I did change the ortho camera to perspective, did not change/fix the up/right vectors though.

[Image: datsville2.png]

I have no idea why the two buildings in the back are all black, I've tried playing with the (recursion) settings but it doesn't matter. I'm afraid my povray skills are very rusty Smile
Reply
Re: Datsville
#44
LOL, I /need/ it to be in ortho though. Also, the buildings are black because they were designed to be black.

Anyway I can see that the pov file is not up-to-date, so here is a new one.

http://www.mediafire.com/?2a99ptd0rdgvc9m



Mike
Reply
Re: Datsville
#46
Here you go

[Image: datsville3.png]

Why ortho? it just makes it look weird imho.
Reply
Re: Datsville
#47
Thanks!!
Reply
Re: Datsville
#48
Sorry to bother you again, but could you re-render with these settings at 6144x3072 pixels?

http://www.mediafire.com/?wd3myxgvs1ns9au

Thanks!
Reply
Re: Datsville
#50
I don't mind these LQ versions render quite quickly.

Here you go

[Image: datsville4.png]
Reply
Re: Datsville
#51
Thank you!
Reply
Re: Datsville
#65
Oops. Disregard.
Reply
Re: Datsville
#49
I'm heavily considering placing Datsville on the following terrain at the location marked with an X.

http://i421.photobucket.com/albums/pp292...c7791a.png

What do you guys think?

My main concerns are:

1. there really isn't a lot of flat ground to place the city at
2. it's going to be tough to remake and position the SNOT roads every time they're needed without some sort of script to auto-generate them
3. if I decide on this terrain there will no longer be a river and I will have to come up with some other creative use for my bridge model Wink

If you want to try your own hand at generating some terrain, I am using World Machine and the project file can be found in SVN here:

https://code.google.com/p/datsville/sour...%2Fterrain


Mike
Reply
Re: Datsville rev224
#52
Revision 224 is ready.

https://code.google.com/p/datsville/downloads/list

There are a few new buildings. The main change however is that I overhauled a lot of the roadways to use fewer, larger bricks. This brought the part count down to under 100k parts.

Enjoy.
Reply
Re: Datsville rev224
#53
During the work on MPDCenter I discovered a mistake in this release.
In file vehicle_017_graysemitruck.ldr there are references to:
vehicle_014_1.ldr
vehicle_014_2.ldr
vehicle_014_3.ldr

Those files are nested in the file vehicle_014_blacksemitruck.mpd and therefore not accessible from outside of that file!

By the way, there are 538 references to '~Moved to' files.
Reply
Re: Datsville rev224
#54
I'll fix the missing sub-models, thanks!

How do I get rid of the 'moved to' parts?
Reply
Re: Datsville rev224
#55
Currently it is not very easy. You need to open a file in MPDCenter. From menu command 'information' choose 'check for ~Moved to files. MPDCenter looks for those files and tells you the number of lines where a reference to a ~Moved to file is found. Then you are asked for action to substitude those references.

I hope this quick description from my mind will help.

I am still working on MPDCenter to fully support also such complex models like datsville.ldr.
Reply
Re: Datsville rev224
#56
OK, great!
Reply
Re: Datsville rev224
#58
Great progress is made on MPDCenter the last days.
Datsville can be loaded, all relevant files imported and then saved as xmpd file.

While working with it I found that there are many file that are not used! Currently there is no option where I can copy and paste my findings. So this is another item I have to change in code.

Next step before the next release should be the possibility to export datsville and restore the old files.
Reply
Re: Datsville rev224
#59
Awesome! But which files are unused?
Reply
Re: Datsville rev224
#60
I just changed the code an now I get the following list of files, that are not used if I view datsville.ldr:

The file 'building_021_badhous1.ldr' in building_021_houseporchyard.mpd is not used!

The file 'building_060_table_small.ldr' in building_060_icecreamparlor.mpd is not used!

The file 'building_009_cargo.dat' in building_009_miningfacility.mpd is not used!
The file 'building_009_dozer.dat' in building_009_miningfacility.mpd is not used!
The file 'building_009_worker.dat' in building_009_miningfacility.mpd is not used!
The file 'building_009_loader.dat' in building_009_miningfacility.mpd is not used!
The file 'building_009_digger.dat' in building_009_miningfacility.mpd is not used!

The file 'emebase.dat' in building_044_amateurradioclubbuilding.mpd is not used!

The file 'building_031_prp_hypertank.dat' in building_031_carriagehouse.mpd is not used!
The file 'building_031_prp_sgn_fire.dat' in building_031_carriagehouse.mpd is not used!
The file 'building_031_prp_sgn_medic.dat' in building_031_carriagehouse.mpd is not used!
The file 'building_031_rck_tank.dat' in building_031_carriagehouse.mpd is not used!
The file 'building_031_lmp_ceiling_1.dat' in building_031_carriagehouse.mpd is not used!
The file 'building_031_lmp_ceiling_5.dat' in building_031_carriagehouse.mpd is not used!

The file 'skelet.ldr' in building_071_redbarn.mpd is not used!
The file 'vaeg.ldr' in building_071_redbarn.mpd is not used!

I just discovered a bug in my code and know that the last two are used.
I also checked the building_031_carriagehouse.mpd and yes, those files in the mpd are not shown if i look at datsville.

So at present this can only be a guideline. I keep you informed about my progress.
Reply
Re: Datsville rev224
#61
Ok, I changed the code. Problem was that I did not parse xmpd files line wise like I do with the other files. I just loaded the file in one string and used a function from vb.net to split that string at '0 FILE'. That works fine as long as this particular string is not used anywhere else. I used this because it can be coded in a minute Smile
I datsville project there is now one file where the string '0 FILE' occur as comment and therefore my old code failed.
Based on the new code here is the list of not used files in the datsville project:

The file 'building_021_badhous1.ldr' in building_021_houseporchyard.mpd is not used!
The file 'building_060_table_small.ldr' in building_060_icecreamparlor.mpd is not used!
The file 'building_009_cargo.dat' in building_009_miningfacility.mpd is not used!
The file 'building_009_dozer.dat' in building_009_miningfacility.mpd is not used!
The file 'building_009_worker.dat' in building_009_miningfacility.mpd is not used!
The file 'building_009_loader.dat' in building_009_miningfacility.mpd is not used!
The file 'building_009_digger.dat' in building_009_miningfacility.mpd is not used!
The file 'emebase.dat' in building_044_amateurradioclubbuilding.mpd is not used!
The file 'building_031_prp_hypertank.dat' in building_031_carriagehouse.mpd is not used!
The file 'building_031_prp_sgn_fire.dat' in building_031_carriagehouse.mpd is not used!
The file 'building_031_prp_sgn_medic.dat' in building_031_carriagehouse.mpd is not used!
The file 'building_031_rck_tank.dat' in building_031_carriagehouse.mpd is not used!
The file 'building_031_lmp_ceiling_1.dat' in building_031_carriagehouse.mpd is not used!
The file 'building_031_lmp_ceiling_5.dat' in building_031_carriagehouse.mpd is not used!

All these files are not visible if you look at datsville.ldr.

If there is somebody out there that is willing to help to make MPDCenter better, please let me know, so I can send the latest build to you for testing.
Reply
Re: Datsville rev224
#62
Will you be able to fix the "moved to" parts as well? I just ran the L3P converter and a lot of "moved to" parts were detected during the conversion.
Reply
Re: Datsville rev224
#63
I know my library is not uptodate but I was able to detect more than 500 ~Moved to files and correct them automatically Smile
That's what MPDCenter is meaning for.

Attached the latest version of
1) loading datsville_rev224 into MPDCenter
2) collect all files that are referenced from the file datsville.ldr
3) correct all ~Moved to files
4) write the content like readed (separate files).

So the file structure in the zip should be exact the same as before.

I hope you like it Smile I do!


Attached Files
.txt   datsville_new.zip.txt (Size: 625.29 KB / Downloads: 0)
Reply
Re: Datsville rev224
#64
Revision 224 is out of date. Could you do that again with revision 256 in the new thread?
Reply
Re: Datsville terrain slope dilemma
#57
I've come to sort of a dilemma when deciding how steep the slope of the heightfield terrain (attached to this post) should be. Currently I have calculated the heightfield such that the shallowest slope matches part 4515, the next shallowest matches part 60477, and the next shallowest matches part 4286.

[Image: slope_dilemma_zps6818d994.png]

The problem is that the terrain then rises in multiples of 128 ldu, which is not evenly divisible by 24 ldu (the height of a standard LDraw brick) and thus you cannot simply stack bricks upon each other to get to this height. You have to add a few plates.

Which is more important? That the slope matches official bricks, or that you can build to this height using bricks alone?


Attached Files
.ldr   terrain_stepped_standin.ldr (Size: 2.47 MB / Downloads: 0)
Reply
Re: Datsville rev256
#66
Roland, could you render the attached POV file for me please? Thanks!


Attached Files
.txt   datsville_rev256_povray.zip.txt (Size: 2.11 MB / Downloads: 0)
.txt   datsville_rev256.zip.txt (Size: 519.73 KB / Downloads: 0)
Reply
Re: Datsville rev256
#67
I would have rendered this, but please let me know what I need to download for

#include "CIE.inc" // http://www.ignorancia.org/en/index.php?page=Lightsys
#include "lightsys.inc" // http://www.ignorancia.org/en/index.php?page=Lightsys
#include "lightsys_constants.inc" // http://www.ignorancia.org/en/index.php?page=Lightsys

cu
Mike
Reply
Re: Datsville rev256
#70
Visit this page:

http://www.ignorancia.org/en/index.php?page=Lightsys

and go to the Downloads section. Everything you need is contained in "lightsys4c.zip". You'll need to either dump them in the same directory as Datsville, or add the directory to POV-Ray's library paths.
Reply
Re: Datsville rev256
#68
Please see attached file for the updated version now.
I realized that in the original folder there are 273 files, but MPDCenter only exports 227 files.
I did not check for the differences, so please be careful with any further change.


Attached Files
.txt   datsville_rev256a.zip.txt (Size: 668.58 KB / Downloads: 0)
Reply
Re: Datsville rev256
#78
Thanks. One problem though. I tried viewing Datsville in LDView but the program crashed due to a runtime error. Is it working for you?


Mike
Reply
Re: Datsville rev256
#81
Yes, that version works for me here. I just also tried to make Pov-Ray export. Please see my other post in this thread from today.
Reply
Re: Datsville rev256
#69
Michael Horvath Wrote:Roland, could you render the attached POV file for me please? Thanks!

datsville_rev256.pov gives a parsing error on line 51276 about a stray '}'. the other datsville.pov seems old.
Reply
Re: Datsville rev256
#71
It's a bug in L3P I think. Does Lars Hassing post here at all?
Reply
Re: Datsville rev256
#72
Have you tried LDView POV export?
Reply
Re: Datsville rev256
#73
I haven't used it because I want to preserve the camera position and materials of my previous renders. I'm guessing that LDview output may use different settings.


Mike
Reply
Re: Datsville rev256
#74
IMHO it should be possible to overwrite this data with your old camera settings etc in the POV file manually.

/Max
Reply
Re: Datsville rev256
#75
I just try it.
Now Pov-Ray claims for two files
#include "lg_defs.inc"
#include "lg_color.inc"

I know from the past, that these files are anywhere and that I need to adjust POV-Ray to find them, or put them in the same directory as the file i want to render.

It would be a great benefit for the user, if this can be checked by LDView on export.
Also I have been in the help of LDView, but no word about those two files. Very disappointing.

Nowadays we should take into consideration that most people just want to use applications and do not want to know much about the background. At least on the first stage. Later on they ask how to tune the results. That's ok and might take some time to figure out how, but not at first stage.

Maybe Travis can take a word on this, as I only remember these things very vague.

Edit: Maybe it was an error on my side. The XML option was checked, but no xml file specified. After I unchecked that option Pov-Ray starts working quite a time but stops at line 593479 due to wrong filename:
#declare LDX_tr�_dot_ldr = union {

I have to check where this wrong file name is from. Maybe wrong character in one of the files of datville that is not really UTF8 without bom, respectively pure ASCII in the original issue.
Reply
Re: Datsville rev256
#80
I am not using LDView to export the POVray file. I am using "L3P.exe".


Mike
Reply
Re: Datsville rev256
#76
OK, I attached a version that is hopefully fixed.

Thanks!


Mike


Attached Files
.txt   datsville_rev256_povray.zip.txt (Size: 2.1 MB / Downloads: 0)
Reply
Re: Datsville rev256
#77
I managed to fix the previous .pov, and rendered this:

[Image: datsville_rev256.png]

I didn't see you new version untill now, I take it it hasn't changed model wise, or do I have to rerender?

ps: the .pov failed because of 'moved to' stud objects which end up without any object info when L3Studs is false. Comminting the if then stuff away for the part in question fixes it.
Reply
Re: Datsville rev256
#79
Very good, thank you! No need to re-render.

Thanks!!


Mike
Reply
Re: Datsville rev267
#82
New screenshot and map.

[Image: th_ldview_screenshot_017_zpsbe8ecca8.png][Image: th_datsville_rev267_map_zps47dd4840.png]
Reply
Re: Datsville rev267
#83
This was the first time, that I looked for the details in Datsville. :-) Very impressive.
You told in another post, that it is CA-licensed?! I'm wonder if the backhoe on the low bed trailer is a copy of set 6662. Isn't it?

/Max
Reply
Re: Datsville rev267
#84
Yes. I suspect it's not the only one as well. Which may put the future of this project at risk. Sad

If you notice anything from here I would appreciate it if you let me know as well.
Reply
Re: Datsville streets organization
#85
I've subdivided Datsville buildings into "blocks" sort of like a Voronoi diagram. I am very happy with this organization. It is very simple and easy to manage.

See here. The blocks are labeled in cyan colored text.

[Image: th_datsville_rev267_map_zps47dd4840.png]

However, all the streets are combined into a single "layer", and this layer has a huge number of parts in it. This causes processing times to slow to a crawl when I view this layer.

[Image: th_ldview_screenshot_011_zps2885698b.png]

What would be a good way to organize the streets into smaller groups or cells? Again, maybe use the Voronoi diagram metaphor. What would you do with the line segments separating the cells?

I'm stumped.
Reply
Re: Datsville rev298
#86
Revision 298 is up.

https://code.google.com/p/datsville/downloads/list

L3P is spitting out a bunch of errors I don't understand. For instance:

Code:
SKIPPING "vehicle_025_redmotorcycleandwhiterider.mpd" Line 1063: Subfile dx901.d
at already read: 2 24 9 -5 3.1 9 -5 24
SKIPPING "vehicle_025_redmotorcycleandwhiterider.mpd" Line 1064: Subfile dx901.d
at already read: 2 24 9 -5 3.1 13 -5 3.1
SKIPPING "vehicle_025_redmotorcycleandwhiterider.mpd" Line 1065: Subfile dx901.d
at already read: 2 24 9 5 24 9 5 3

There are also several warnings in the POV file itself:

Code:
// WARNING: building_001_3024.dat not resolved
// WARNING: building_001_3024.dat not written to POV file
// WARNING: building_031_floor.dat not resolved
// WARNING: building_031_floor.dat not written to POV file
// WARNING: 6099p01.dat not read
// WARNING: 6099p01.dat not resolved
// WARNING: 6099p01.dat not written to POV file
// WARNING: building_062_floor_3.ldr not resolved
// WARNING: building_062_floor_3.ldr not written to POV file

What do these errors mean?
Reply
Re: Datsville missing models
#87
I found some stuff on Brickshelf that was intended for Datsville but never made it into the model.

http://www.brickshelf.com/cgi-bin/gallery.cgi?f=280862
http://www.brickshelf.com/cgi-bin/gallery.cgi?f=713

Wouldn't it be cool if the models were finished and submitted?
Reply
Re: Datsville rev308
#88
You can download the new revision from here:

https://code.google.com/p/datsville/downloads/list

1. In this version I split the street layer into sectors so we don't have to load the whole model and suffer slowdown when editing.
2. In this version I also made sure that vehicles and pedestrians are firmly fixed to the ground beneath them instead of floating in the air or stuck inside a wall.
3. I added a few more vehicle models by Tim Gould. Great work!
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)
Forum Jump:


Users browsing this thread: 1 Guest(s)