iceleftd

@msx80 - My next area of focus is the dreaded "transparent objects cast shadows" problem. According to the Sunflow Wiki PDF, you can work around this in the mirror shader by turning on caustics. Trying to do that, however, results in a NullPointerException. java.lang.NullPointerException at javafx.embed.swing.SwingFXUtils.fromFXImage(Unknown Source) at bluerender.a.a(Unknown Source) at bluerender.BlueRender.a(Unknown Source) at bluerender.BlueRender$$Lambda$278/490108022.run(Unknown Source) at com.sun.javafx.application.PlatformImpl.lambda$null$170(Unknown Source) at com.sun.javafx.application.PlatformImpl$$Lambda$48/730214495.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$171(Unknown Source) at com.sun.javafx.application.PlatformImpl$$Lambda$47/1789447862.run(Unknown Source) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(Unknown Source) at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at com.sun.glass.ui.win.WinApplication.lambda$null$145(Unknown Source) at com.sun.glass.ui.win.WinApplication$$Lambda$36/683287027.run(UnknownSource) at java.lang.Thread.run(Unknown Source) Another spot in the Wiki says "In the uber shader, setting the spec color to 0 0 0 and spec.blend to 0 will allow transparency, though this won't translate to transparent shadows at the moment.". That sounds encouraging, but is it a false trail? You have been so productive and responsive so far - thank you!

Feature Request: Reflectivity is set by default to .2 on individual material definitions, which results in models that are unnaturally reflective (real bricks just aren't all that mirror-like, even right out of the box). I would suggest changing it to a more modest .05 by default to make it more natural looking. Others may have a better value suggestion.

As far as I know there are only 309 and 310 (Chrome Silver and Chrome Gold, respectively). There are quite a few other chrome colors that have been produced over time but they don't have corresponding color ids. Here's what I'm using. shader { name mat309 type mirror refl 0.80784315 0.80784315 0.80784315 } shader { name mat310 type mirror refl 0.8745098 0.75686276 0.4627451 } To quote Scott Barnick on Flickr: So while it is possible to create entries for the other chrome colors with the appropriate RGB values, there would be no element color in LXF for them anyway. Finally got to test it. It looks MUCH better now! How did you do it?

So by default, we should have something in place overhead (at least when we have reflective parts). Perhaps it could be white or off-white with the ability to uncomment and supply an image path instead? It seems odd that SunFlow doesn't have some setting for what to do when rays bounce off into infinity (other than return black). That kind of solution would make a fix quick and easy. I see the shadow effect with your example sky plane. So does the sunsky have a vertical position or is that faked too? Could you possibly put the sky/roof plane above the light source to avoid the shadow effect? (Sorry for the ignorant questions.) Ultimately, I just want the renderer to do something normal and expected so that 95% of the people who use this don't ever have to edit a scene file or learn SunFlow. Changing the material definitions for the silver and chrome colors is a must, but that brings up the lack of a roof/sky overhead. Adding in a roof/sky (at least how you did it) runs afoul of the shadow problem, making that solution unusable. I would like to promote Bluerender at a LEGO convention at the end of July, so I'd like to see as many feature in there as possible. On the other hand, I don't want to make msx80's job harder than it already is - I want him to work on Blueprint again someday too!

Thank you! It appears you solved the "blackness" problem, but I am going to ask for some clarification. You seem to be mixing two issues - getting rid of the blackness and supplying an image for the sky. Please explain their differences or how they are related. What exactly was the source of the blackness? It can't be the transparent shadow issue because that would affect the whole image. Please supply the scene file changes you used to get the first image. I would hope that the default scene file would eventually include such a change (along with the metallic color changes). You and msx80 are very knowledgeable about rendering, but one would hope that this tool would be very accessible to those who are not. That's why I am pushing to get the default settings to something that doesn't require changes for most people.

PM-ed you a link.

Please message me your email address and I will send the files.

I thought I was being clear. I want the sky to be something other than black in every direction so reflective surfaces don't show as black in an otherwise "sunny" image. I couldn't get a second, overhead, plane to work, and the Sunflow doc talked about a code change to tell the SunSky light to extend in all directions. When I looked at the Sunflow code for that shader it looked like it should be supported as an option. But the parser ignores that option. Of course, with no access to the source and the compiled code obfuscated, I have no idea whether his code has been modified from the Sunflow distribution or not. If you can show me how you make a chrome part not reflect black from the sky, I would be very pleased.

By comparison, here is the same model rendered with POV-Ray - default settings, quality 8 (lowest with reflection). Note there is a reflection of a diffuse sky. POV-Ray reflection comparison by iceleftd, on Flickr I did try putting up a plane but it blocked the sunsky light - not what I had in mind. Maybe putting a plane high enough might work. I haven't figured out how to get IBL/HDR to work yet... :P I did find this online: Looking at the source code online it looks like the code doesn't need modification, and that the scene file should support "ground.extendsky true" after "samples" but it doesn't like that syntax. That support was added in April 2007 so I can't imagine this doesn't support it. Any ideas?

Well done! I don't have a sunken model to test anymore but thanks for automating that fix for us. Loading is very quick again as you say. I've been looking at images to identify what I don't like and see if I can figure out how to change the scene file to fix them (sometimes stumbling in the dark). I noticed that the shaders for the chrome colors are incorrect. They should be replaced with something like this: shader { name mat309 type mirror refl 0.80784315 0.80784315 0.80784315 } shader { name mat310 type mirror refl 0.8745098 0.75686276 0.4627451 } But that pointed out another problem. Chrome parts reflect the sky (ceiling) too, but the sky appears to be black. Bluerender Chrome test by iceleftd, on Flickr Now I guess that makes sense because there is no "sky" object/plane above, but this looks pretty awful. I tried fiddling with some solutions but nothing worked for me. Ideas anyone?

Your command window output indicates that the java/bin folder is not in your default path. That is very odd as that normally is set when you install Java. Try creating a command window and issuing the command: c:\>echo %PATH% In the output you should see a string for the Java bin folder. If not, you should probably reinstall Java.

Not a dumb question. This is not an installed program. You simply unzip the files into a directory, navigate into it and click on the .BAT file to start the program. You must already have LDD installed (to get the parts library) and have Java 8 installed (preferably the 64-bit version). That's it!

My original post with that suggestion included the fact that the cache would be purged if the LXF file path or timestamp was changed so that wouldn't be a problem. Sorry I didn't repeat that the second time.

The files weren't that old, but resaving it did seem to fix the problem the renderer had. That makes two problems like that so far (model sunk into the plane was the first). So what is your philosophy on how much effort should be put into compensating for "flaws" in LDD (assuming you had the time to do something about it anyway, we are talking hypothetically now)? Is the right answer always, "Try resaving your LXF file"? Just curious. Yes, the loading phase. Not sure why linear loading became significantly slower between v1 and v2, but parallelism should help. I find myself doing multiple renders in a row of the same model while fiddling with the scene parameters, and yet each time I render it re-reads the model geometry and parts. It really does seem to me that the best approach would be to process the LXF file just once and cache that data for reuse if the LXF file has not changed. (I am assuming here that the loading phase doesn't apply the scene data at the same time. If it did, the two processes would have to be separated for that to work.)

Nick - Despite all your warnings about imminent software explosions, until now I never had a problem with the working of Bluerender (unless I screwed up the scene file). Today, I tried to render a model and got this: BRICK Part 431 6111 (BRICK 1X10) Colors:194 BRICK Part 444 3008 (BRICK 1X8) Colors:194 BRICK Part 532 58124 (FUNC. PLUG TOP) Colors:199, 26 java.lang.ArrayIndexOutOfBoundsException: 2 at bluerender.BlueRender.a(Unknown Source) at bluerender.BlueRender.b(Unknown Source) at bluerender.BlueRender.c(Unknown Source) at bluerender.BlueRender$$Lambda$175/67551355.run(Unknown Source) at java.lang.Thread.run(Unknown Source) How do you want to solve these kinds of problems? The best way, I suppose, would be to send you the LXF file privately for you to test with yourself in the debugger. I really wish this was a collaborative build - I'm itching to get into the code! P.S. I agree with bublible that the render preprocessing is much slower in V2. Makes me wish for caching even more.

Another observation: Doing a higher-res image, I was averaging about 65% CPU (8 core machine). This is in contrast to POV-Ray which runs all cores at 100%. After realizing I was running 32-bit Java, I upgraded to the 64-bit JDK. Now all cores run at 100%. Thought you all might find that interesting.

Thanks for the help! It might just be easier and quicker to have BlueRender detect the problem and correct it when loading the file.

But I thought that adding a lower brick moved the floor in LDD so the entire model is always at or above y0. Is that wrong? Moving the entire model and resaving did seem to fix the problem, but isn't that some sort of bug in LDD? I can easily imagine not noticing that little of a difference when rendering if the base is made of bricks and that worries me.

I found this interesting behavior with one of my models (using either 0.0.1 or 0.0.2). The upper image uses the default settings for the plane and the model appears to be partially submerged in the plane. I'm guessing there is some problem with figuring out the default plane location. Changing the shader value ("p 0 -.3 0") seems to correct the problem, as shown in the lower image. If I didn't have a baseplate on the bottom, though I might not have caught this issue. Floor render problem by iceleftd, on Flickr

Thanks for the sneak peak! <salivating> P.S. you should update the readme with a list of changes for each version. See! Even more to do today! :P

Okay, thanks. I wasn't thinking straight. I figured it was probably a vector (although not knowing which axis was which), but I had incorrectly been thinking about ranges of [0, 1], rather than [-1, 1] which makes more sense. It was late so I'll use that as my excuse. ;) Still, the only doc i could find on these parameters was a PDF compilation from an old wiki. Is there an actual reference somewhere for these parameters? Another suggestion: Every time you render, you reread and pre-process the LXF file. I suggest you cache the result in memory and reuse it if the LXF path and file timestamp has not changed. This will only save a handful of seconds today, but if you ever add additional pre-processing such as bevels or "LEGO" on the studs it will save a lot of time on re-renders. If you ever get that far, you could even switch to a persistent cache (possibly using ehcache?). That was always something that annoyed me about POV-Ray!

So now I've run into the "sun behind the model" problem, but I can't figure out how to change the sunsky options to move the light source. I'm a pretty smart programmer but everything I thought might work just made the image darker. The SunFlow documentation (such as it is) sheds no light and I don't want to invest in reading all the SunFlow code. A workaround was alluded to earlier but no explanation was given. Can someone help me out?

Hmmm... Options are good, but what about this idea? "Fade" all the parts placed in previous steps. I'm not sure of the best way to do it, but maybe change the transparency (alpha value)? That would "fade" the bricks you aren't as interested in while leaving the "new" bricks normal looking, but highlighted by comparison. You could allow a choice between multiple highlighting options (outline, pink, fade other bricks, none). Yeah, about that. As I worked on moving steps and submodels around, I had no idea what the pages would look like until I switched modes and rebuilt the Page View. There are a couple of ways to solve that. One way would be to have some sort of preview window that would show you the pagination in real time (something like the "filmstrip" view in PowerPoint that shows you small versions of all the slides). I can see a lot of problems with that, though, so how about this idea which would be much easier. In Step Design, you could put an inert vertical bar between steps every place there would be a page break. Depending on the time cost, that might require a new way of doing incremental repagination (ouch). I tried that suggestion and it has its own drawbacks. You can't change the order of the submodels once they are created (also later created submodels appear first). You end up with that one step with all the subassemblies together. Yes, you can rearrange them on the page but what you really need is the ability to use other steps to assemble them. It's also silly to have this big complicated "Step 1" and no other steps. Any way we could make submodels end up producing a "virtual part" that could then be used in parent model steps? That would allow for ordering, rotation, etc., as it may be very important how they are stuck together. I see your dilemma. Perhaps you could recruit some private help then, as we expect a lot from you now! ;) Additional ideas: You should have a way to change the order of submodels within a parent model. If a context item is not valid (such as delete step because there are parts or submodels), disable the context item rather than allow the click. Better yet, lets put a tool bar on an edge of the step image: A red X button to delete the step (disabled if invalid because of parts or submodels). That will save a lot of time for me too as I delete steps often. Left and right arrow buttons to facilitate horizontal step movement Up and down arrow buttons to allow steps to be demoted to a submodel or promoted to the parent (tricky as there may be multiple submodels - also disabled as appropriate). Each demotion now requires three steps: making a new step in the submodel, moving all the parts, and deleting the old step. [*]A way to "collapse" and "expand" a submodel into a single column. This would make it easier to navigate. You could use another button for that action like you often see in tree views (perhaps shifting between + and -). [*]With multiple submodels it's not easy to see the hierarchy. There could be some low-tech ways to do that, such as a bar above the models that shows the groupings graphically, or possibly by "indenting" submodels by adding some headroom for each depth level. Sorry to be so full of advice on multiple subgroups but I think this is an area that needs to be dealt with or you won't be able to effectively handle large assemblies.

A couple more requests (apologies if they are repeats). Scale the rendering progress image to the size of the window so you can see the whole thing (or at least scale it if it's bigger than the current window size). During rendering, on the main screen display the percentage done, elapsed time, and expected remaining time. Even though it's fast it would be nice to know right away if something will take a long time because you might want to cancel it and change settings (right now I'm trying a higher resolution image and I have no idea how long it will take, and I can't even see the whole image in the progress window to guess).

Is this where you want to get feedback/suggestion/bugs? Working on that assumption... I made my first set of instructions today using Blueprint. There were some definite difficulties, but overall I was surprised at how well things turned out. Some observations: Thank you thank you thank you for putting undo/redo in. I had started with 0.0.14 and it was painful. Page setup could use top and bottom margins, as well as minimum padding between steps. The empty submodel issue is really hard to deal with - please fix soon :) In Step Design, using the context menu for rotation is quite painful because you often need a great many rotation attempts before figuring out which ones you want and being happy with the result. I suggest tying step rotation to the arrow keys and model rotation to the arrow keys with the shift key in addition to the context menu. Even better would be to have drag-rotate like you can do in the palette in LDD. The submodel background colors are not configurable but should be. One of the default ones didn't look good with black parts and pink highlighted ones. If I have step that places two 4x4 plates of different colors, the current highlighting scheme means that image is useless. You have to look at the next step image to figure out the placement. It seems an unnecessary restriction to split every color part into a different step. Would it be possible to simply highlight the outline of the parts in the step image? Page Layout view could use drag-select (thank you for multi-click-select). It would be nice if page layout view could also allow movement of selected items by arrow keys. That way, if you just want to make some vertical space between steps you could use the up and down arrows without messing up your horizontal alignment. I appreciate the power to move steps around freely on the page, but how about some way (context menu?) to distribute them evenly on the page and another to return it to the default layout? That particular option could also have a default in page setup, but you would still have to be able to override it per page. I think the current submodel scheme has a flaw. If I have a model that has a single submodel in the middle, the current scheme is fine. It generates steps [1, 2, 3, 4, 5, [sub1, Sub2, Sub3, Sub4], 6, 7...] where the brackets indicate page groupings and step 6 integrates the submodel back into the main step flow. My model had three submodels to build and then then put together at the end. Lets call the submodels A, B and C and their submodel steps A1, A2, etc. When the instructions are generated, I get steps [[A1, A2, etc.], [1], [b1, B2, etc.], 2, 3]. So step 1 ends up on its own page and just repeats the last image from the submodel with every part highlighted. It would have been better to have [[A1, A2, etc.], [b1, B2, etc.], [1, 2]], where step one joins the first two submodels. To make things worse, submodel A has two submodels of its own (AA and AB). This generates [[[AA1, AA2, etc.], [A1], [AB1, AB2, etc.], [A2], [1], [b1, B2, etc.]. [2, 3, etc.] so we have even more single-step pages that are isolated in the instructions, and both A1 and 1 are simply repeats of the previous image but with everything highlighted. Not sure of the best solution, but the current way isn't right. [*]Overall I'm very upbeat about this - Nice job! Is this something you are going to open source so that others can contribute to it? I'm a Java developer (although not really a GUI developer), so I am curious.