LDView Travis

Eurobricks Vassals
  • Content Count

    19
  • Joined

  • Last visited

Everything posted by LDView Travis

  1. Put the above into a file that's in your POV-ray include path, then set that as the "Top include filename" in the General section of LDView's POV Export Options. This will cause it to always be used. Of course, if you need to change the color for each model, don't do this, unless you want it to simply match the floor color, in which case you can use LDXFloorR, LDXFloorG, and LDXFloorB. Note that your top include can include any and all custom overrides that you want. For example, if you don't like LDView's default lights, put your own lights into your top include (using the same declares that are used for LDView's lights, but with different locations), and then define LDXSkipLight1, LDXSkipLight2, and LDXSkipLight3.
  2. When I said that the refraction looks wrong in the first image, I meant that is (to me) the main difference between the first (faster) render (using non-transparent LGEO bricks), and the second (slower, more accurate) render. In other words, I was saying that the more accurate transparent LGEO bricks (that take longer to render) do, in fact improve the picture IMHO.
  3. To me, the refraction looks all wrong in the first image. I think that's because the pieces aren't being treated as being solid.
  4. If you manually edit the file, you might be able to change the value of lg_quality on the fly. Have it set to one value for the top layer so the logo appears, then change its value before doing the other layers. No guarantees, but it might work.
  5. Note: you should be able to put this code into an include file, set that file as the top include in LDView's export settings, and then add the following to the include file to have LDView's generated lights be ignored: #declare LDXSkipLight1 = 1; #declare LDXSkipLight2 = 1; #declare LDXSkipLight3 = 1;
  6. No. C3POwen just rotated the studs, not the rest of the part. Rotating the rest of the part would cause it to no longer match the official one, which would break any models using it. The LGEO part is wrong, so my posted LGEO.xml fix is still needed. C3POwen's fix is only visible if you have stud logo textures enabled in LDView, or have a custom stud primitive that includes the "LEGO" text.
  7. 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.
  8. If you send your LDraw model (not the POV model) to LDView's e-mail address, I'll investigate.
  9. 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: Add the following line immediately after the above: Then, do a search in the file for 2539.dat. In the definition for that Element, you'll see the following: Change it to the following: 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.)
  10. 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.
  11. 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.
  12. 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.)
  13. This list would definitely be useful. I plan to add all the ones that you already added to your custom LGEO.xml, but any others that are found would be good too.
  14. 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).
  15. Unless you're looking at a different cannon, it should look fairly good. Not perfect, but fairly good. However, some parts (like minifig heads) just don't look good, and there's not really anything you can do. Feel free to post a picture of the cannon so that I can verify you're getting the same results I got.
  16. Selecting the "Primitive Substitution" option in the POV-Ray export options causes LDView to use precise POV objects to replace LDraw primitives, where possible. For example, an LDraw cylinder primitive is replaced with a POV cylinder object (properly configured), instead of being made up of triangles. This can cause gaps in the POV objects where surfaces that use primitives meet surfaces that don't, but generally looks quite good. In addition to this, LDView has a "Smooth curves" option in the POV-Ray export options. This uses the original geometry from the LDraw file, but smooths out curves visually by giving shared surface normals for points on the curve. Unfortunately, LDView's curve smoothing algorithm isn't perfect, so sometimes surfaces that should be smoothed, aren't. However, I would definitely recommend selecting this option. I did a quick render of the cannon (518.dat), and it looked pretty good. LDView automatically generates three default lights. The comments next to the lights give their locations in spherical coordinates relative to the center of the model. LDXRadius is a value calculated by LDView and stored in the POV file as a variable, and it represents the radius of the smallest possible sphere centered at the model's bounding box center and encompassing the whole model. So, if you want your own lights, I would recommend putting them into a top include. The top include has access to all of the model's bounding information: LDX{Min|Max}{X|Y|Z}, LDXCenter{X|Y|Z}, LDXRadius. You'll have to do your own math to decide where to put them. If you do this, you can define LDXSkipLight{1|2|3} to prevent LDView's default lights from being used.
  17. Thanks, C3POwen. Unfortunately, it doesn't look like I'm going to be able to include the colors as-is, since they rely on your custom lg_color.inc file. I'll have to think about whether I want to allow for a separate custom color file, and then include that with LDView. I also investigated your removal of 51011.dat. I discovered that lg_51011 works fine as long as the POV-Ray version is set to 3.1 prior to the lg_51011.inc #include, so I think I'll add a POVVersion element to my XML syntax, and then update LDView to use that as a trigger to generate save version/update version/#include file/restore version in place of just #include file.
  18. I just created my account here, and it's not allowed to view other member profiles, so I don't think I'm capable of sending a PM.
  19. Hopefully the invalid part references that LDView was spitting out have been fixed in the 4.2 Beta 1 release that I just announced today. Also, C3POwn, if you would be so kind as to send me your updated LGEO.xml, I'll investigate including it in the next official LDView release (with your permission).