320 replies to this topic

[C3POwen]

palathadric, on 17 May 2012 - 09:46 PM, said:

I have one question C3POwen. You use both LDD and LDraw. What would you say are the benefits of using LDD? I worked with it for a while, but found it very slow, and quite unwieldy in comparison to, say, SR 3D Builder.

LDD (the official LEGO software) is great, as it is incredibly easy for anyone to pick up and use. However, there are collision issues in some parts, which makes it difficult to recreate some models virtually, and it cannot export files with which to create the kind of renders that I like. With LDD, what you see is what you get. Also, the library of pieces is currently entirely dependent on LEGO creating them.

MLCad, the LDraw interface that I prefer, is not so quick to use for building and has a steep learning curve for some things (such as LSynth), but I find it more precise when it comes to brick placement, and it supports some clever things such as LSynth and exporting models to POV-Ray files via LDView, and it has a very customisable parts menu. As the parts library is user-created, it will continue to grow, and there is even the ability to convert parts from LDD to the LDraw format, if you know how. The MPD (Multi-Part Dat) format function is also very handy, and I find having actual submodels more useful than using groups.

SR 3D Builder is a good alternative to MLCad, as it has a more LDD-like interface, but I found the positioning a bit clunky (which might just be me), and there is currently no LSynth support (which I am a big fan of). The locking pieces function is great though, and it'd be good to see something like this in MLCad (which has already been proposed). The ability to have working Technic gears and animations is also a great idea.

If you want to use the LDraw parts library, but want something easier to use than MLCad, then SR 3D Builder is probably for you.

[Palathadric]

I don't like the brick placing of programs like LDD and LeoCad (I think, I haven't used the latter in a while), because it can really tend to be hit and miss (as Otaku mentioned, it could be 100 studs away). The grid system of MLCad and SR 3D Builder I find much easier to work with.

Also, for minifigs MLCad seems to be an almost no-go zone. It's really not minifig friendly at all, from what I've seen.

[LDView Travis]

palathadric, on 19 May 2012 - 01:08 AM, said:

Also, for minifigs MLCad seems to be an almost no-go zone. It's really not minifig friendly at all, from what I've seen.

If you want to do minifigs in MLCAD, you need to use its minifig builder tool (which then creates an MPD sub-model for the minifig once it's built). Unsupported minifig parts can be added to its INI file.

(Note: despited creating LDView, I really don't do any LDraw modeling, so I really don't know much about using the tools, but I do know that MLCAD has a minifig creation tool, and that's the way to create minifigs in MLCAD.)

Edited by LDView Travis, 19 May 2012 - 03:01 AM.

[Palathadric]

But I think moving the body parts, especially the arms, and hands, is a big issue in MLCad and it takes a genius to do it right, unless I'm really missing something.

[C3POwen]

palathadric, on 19 May 2012 - 09:52 AM, said:

But I think moving the body parts, especially the arms, and hands, is a big issue in MLCad and it takes a genius to do it right, unless I'm really missing something.

Outside of the Minifig Generator, you're absolutely right. The arm and hand elements to do not rotate along their natural axis, unlike in LEGO Digital Designer. This is a limitation of MLCad (and the LDraw format in general), although if they are able to implement the LDraw Connection Database proposal, then it would solve these issues.

[Palathadric]

C3POwen, on 19 May 2012 - 10:23 AM, said:

Outside of the Minifig Generator, you're absolutely right. The arm and hand elements to do not rotate along their natural axis, unlike in LEGO Digital Designer. This is a limitation of MLCad (and the LDraw format in general), although if they are able to implement the LDraw Connection Database proposal, then it would solve these issues.

SR 3D Builder does not have a problem with this. That is one of the main reasons why I started using it. I also has issues with stacking bricks sideways and no just up in MLCad, but SR 3D's automatic detection feature makes this a breeze. The Taj Mahal was so much easier to do in SR than in MLCad. I originally did it in MLCad, but then I re-did it in SR 3D Builder.

[LDView Travis]

I just wanted to note to the person who left a me a PM, I can't read it yet. My account isn't allowed to see any profile stuff. Somebody else's comment implies that this will change once I hit ten posts. This is post number 9, but I don't think it's right to post for no other reason than to hit 10.

[Palathadric]

I didn't send you the PM, but let me give you a reason to post your 10th.   When is the next version of LDView coming out?

[LDView Travis]

palathadric, on 19 May 2012 - 11:54 PM, said:

I didn't send you the PM, but let me give you a reason to post your 10th.   When is the next version of LDView coming out?

I want to fix the reported bugs from 4.2 Beta 1, and since there haven't been too many of those, hopefully that means that the final 4.2 releas will happen within a month or two.

[TK-949]

How can I render with LDraw colors instead of lg colors? It's just for testing.

Oh, and I had a few renders with your custom lg_color.inc, and all trans neon colors look way too bright. Trans neon orange looks trans yellow, trans neon green looks yellow-whiteish and not even transparent. Is there something I did wrong?

[C3POwen]

TK-949, on 20 May 2012 - 09:38 AM, said:

How can I render with LDraw colors instead of lg colors? It's just for testing.

If you want LDraw colours and don't want to use the LGEO library, I believe you can disable the use of this in LDView's export settings under "Native POV Geometry", disabling "Use XML mapping file". This should then only use LDraw's colours. You could also remove all the colour entries from the LGEO.xml file itself, and you would still have access to the LGEO parts.

TK-949, on 20 May 2012 - 09:38 AM, said:

Oh, and I had a few renders with your custom lg_color.inc, and all trans neon colors look way too bright. Trans neon orange looks trans yellow, trans neon green looks yellow-whiteish and not even transparent. Is there something I did wrong?

The transparent neon colours are something that I'm aware of, but have not got around to fixing this yet, as I'd like to run some test renders to get it right. At the moment they're set to give off light, hence the brightness (unlike the other colours, which are not). I'll post another version of the lg_colors.inc file over the next few days that I'm happier with.

[TK-949]

Cool, thanks.

[TK-949]

C3POwen, on 20 May 2012 - 12:52 PM, said:

If you want LDraw colours and don't want to use the LGEO library, I believe you can disable the use of this in LDView's export settings under "Native POV Geometry", disabling "Use XML mapping file". This should then only use LDraw's colours. You could also remove all the colour entries from the LGEO.xml file itself, and you would still have access to the LGEO parts.

No, neither of that works, I still get trans yellow instead of trans neon orange. The second solution doesn't work, because some of the lgeo parts refer to lg colors.

[EDIT] hmmm, even with the original lg_color.inc installed I get trans yellow. Now I'm really confused...

[EDIT 2] After reinstalling your lg_color.inc as well as the lgeo.xml file the trans neon orange looks right. Weird.

Edited by TK-949, 20 May 2012 - 04:18 PM.

[Palathadric]

For some reason piece 2539 gets rotated by 90 degrees on its X axis somewhere between LDView and POV-Ray. In LDView I still see it properly, but when I render the model it comes out the rotated, any idea why this is? Is it just a minor bug with this specific part. I thought I'd mention it. I finished rendering all the pirate pictures with POV-Ray, so I just need to shrink them to the correct size and then I'll put them up here. I'd really appreciate and criques as to how I can make the pictures better. Thanks for all your help C3POwen and all!

[Palathadric]

LDView Travis, on 12 May 2012 - 09:59 PM, said:

I think if you add the following to the top of your file, it will work:

#version 3.1;

The above line triggers other changes in POV's behavior, though (as far as I know), so it's possible it will change the final result. The other option is to put the above right above the #include for lg_4475.inc, and then put another #version line right below specifying whatever version of POV-Ray you have (like #version 3.7; if you're using 3.7).

I finally got around to doing this and it works. Thanks so much, Travis! Oddly, when I rendered the Black Seas Barracuda with this "formula" the computer froze, although it finished rendering. I had to restart, but the image is there.

[LDView Travis]

palathadric, on 21 May 2012 - 10:18 PM, said:

For some reason piece 2539 gets rotated by 90 degrees on its X axis somewhere between LDView and POV-Ray. In LDView I still see it properly, but when I render the model it comes out the rotated, any idea why this is? Is it just a minor bug with this specific part. I thought I'd mention it. I finished rendering all the pirate pictures with POV-Ray, so I just need to shrink them to the correct size and then I'll put them up here. I'd really appreciate and criques as to how I can make the pictures better. Thanks for all your help C3POwen and all!

This appears to be a bug in LGEO. It can be corrected by modifying LGEO.xml in two ways. First, search for the following line:

Quote

        <LGEOTransform>0,0,-25,0,-25,0,0,0,0,-25,0,0,0,0,0,1</LGEOTransform>

Add the following line immediately after the above:

Quote

        <LGEOTransformY90>-25,0,0,0,0,0,25,0,0,-25,0,0,0,0,0,1</LGEOTransformY90>

Then, do a search in the file for 2539.dat. In the definition for that Element, you'll see the following:

Quote

            <MatrixRef>LGEOTransform</MatrixRef>

Change it to the following:

Quote

            <MatrixRef>LGEOTransformY90</MatrixRef>

Re-export from LDView, and the problem should be solved. (The LEGO logo on studs is rotated 90 degrees vs. in LDView; LDView uses the orientation from the LDraw file, and while that's likely to be correct, it's not guaranteed. There's no way in LGEO.xml to rotate the rest of the geometry of the part without rotating the studs.)

[Palathadric]

Thanks, Travis. Got them working now. Am just finishing up with rendering the last pirate ships with this method and then I'll overhaul my entire bricklink account and get the new pictures posted in the official sets thread. Thanks all! Once again, when I get them up I would love any constructive criticism you all have to offer. I know they need work.

[C3POwen]

palathadric, on 23 May 2012 - 01:51 AM, said:

Once again, when I get them up I would love any constructive criticism you all have to offer. I know they need work.

I'm sure they'll be fine.

I'm going to try and get some of the radiosity stuff sorted out for this tutorial when I can -- perhaps this weekend -- as I'm a big fan of whitew0lf's renders, and would like to get some more even lighting on my models.

[CheesyErwin]

This is a very helpful tutorial.

Anyway, I encountered a rather strange error. When I exported the model to POVRAY 3.7 via LDView, then starts rendering, then a parsing errors pops up saying:
Parse Error: No matching } in 'material', undeclared identifier 'LDXColor67109987_slope' found instead

How do I fix this?

[LDView Travis]

CheesyErwin, on 24 May 2012 - 04:46 PM, said:

This is a very helpful tutorial.

Anyway, I encountered a rather strange error. When I exported the model to POVRAY 3.7 via LDView, then starts rendering, then a parsing errors pops up saying:
Parse Error: No matching } in 'material', undeclared identifier 'LDXColor67109987_slope' found instead

How do I fix this?

If you send your LDraw model (not the POV model) to LDView's e-mail address, I'll investigate.

[CheesyErwin]

LDView Travis, on 24 May 2012 - 05:11 PM, said:

If you send your LDraw model (not the POV model) to LDView's e-mail address, I'll investigate.

Mail sent. Thanks for your help ^^

[LDView Travis]

CheesyErwin, on 24 May 2012 - 05:50 PM, said:

Mail sent. Thanks for your help ^^

You're welcome. When I export using LDView 4.2 Beta 1, I don't get the error. There was a known bug in LDView 4.1 that caused this problem, which is fixed in LDView 4.2 Beta 1. So, while you might generally want to avoid Beta software, in this case I would recommend updating to LDView 4.2 Beta 1. Your other alternative is to do a global search and replace in the POV file generated by LDView 4.1, and replace LDXColor67109987_slope with LDXColor67109987.

[Palathadric]

Blakbird, on 26 February 2012 - 07:37 AM, said:

Yes. Good radiosity will increase the render time by 10-100X. If there is any transparency involved (like your sample image), the time is much longer again. HDR doesn't really change the render time much. As an example, the sample I made of your render below uses radiosity and HDR and took about 4 hours to render on a quad-core. I also used brighter lights than you did, so that's not really part of the comparison. You will especially see differences in the reflections and in places which were not lit much in the original image.

Image

What POV-Ray settings did you use for this file, Blackbird? It is really good!

[C3POwen]

Palathadric, on 26 May 2012 - 11:35 AM, said:

What POV-Ray settings did you use for this file, Blackbird? It is really good!

Although I can't vouch for Blackbird's settings, I've been playing around with radiosity a bit, and plan to update the guide just after this weekend (as the weather here is too nice at the moment).

POV-Ray (from version 3.5 onwards) has radiosity settings built in, and some info on how to add that can be found here: http://www.povray.or...view/3.6.1/494/

You must specify the #include "rad_def.inc" at the very beginning of the file, and you must also add the global_settings too. I also suggest using the Radiosity_Fast setting when testing your renders.

The results are quite good using Radiosity_Final, but I've asked whitew0lf for some tips on his radiosity settings, as I still get some visual artefacts.

[C3POwen]

GUIDE UPDATE: I have updated the lg_color.inc file so that transparent neon colours do not appear so bright or washed out.