msx80

Well it's surely better than the setting i have now! They look a little too shiny tho, maybe darkening a little? Anyway when we found a satisfying setting i'll include it in the standard scene.sc. About the black, i don't know. The only thing that comes to mind is the one bublible said, have you set a background color different from black? Maybe you could look into official Sunflow and its example if there's something. It's also possible that my tampering of sunflow sources introduced the problem, even if i don't think so Yeah indeed, that's what the clickable label was about :) Actually i think the reason why the janino shaders don't work is becouse i obfuscated the sources, and sunflow sources got caught in the process. (obfuscation means changing all the class names and methods with unreadable one letter names to impede decompilation, a standard practice to protect source code) Eventually in the next release i'll fix it and make sunflow into his own jar library. About SSS shaders, i don't even know what they are :)

Uhm that's strange, can you paste the complete error? What circumstances causes the NullPointer, exacly? Like, you loaded a lxf with a decoration present in the db folder?

As i've some things ready, I've prepared a small surprise new version :P It has the following changes: Model loading is fast again (even faster!) Some textured glass support (not perfect yet) Clickable scene label (opens the scene file) Self adjusting plane height Search file in db folder beside db.lif Bugfixes You can get it here. If anyone wants to give a quick test before i update the main page, it would be great!

Well it depends on the specific problem.. The plane adjustement is clearly something that my program should support, while i'd rather skip on the error on loading older files, at least if it doesn't appear on new ones. If you want to spend some time, you could compare the difference in the old file and the newly saved one to see if something jumps to the eye... Most probably it's a problem in the decoration/material stuff. Pinpointing the problem will surely help :) I plan to keep correcting and improving both blueprint and bluerender, the time to spare is always too little so it will take a while.. I already have dozens of issues open on both programs, i'm slowly marking them down :) I considered using some public issue tracker and moving all stuff there but haven't done it yet. Are you perhaps able to tell the exact phase that got slower? Like the text in the "activity" box? About loading: the loading phase has many steps: first it loads the model in a generic datastructure, the same that is used by blueprint. This phase also loads the single bricks geometry (and should be much faster in the new "parallelized" version). Then the scene.sc file is read and processed (substitutions etc). Then the geometries (that are Sunflow objects) are generated (one for each design id) into a text buffer, and then the instances (one for each brick in the model). After that the three portion are joined into a single text and fed to sunflow. So yes, i could skip reparsing of the LXF quite easily, checking if the lxf has not changed and keeping the buffers in memory. I have to check for memory issues (keeping giant buffers consumes ram) but should be doable! Didn't meant to be rude, in case it wasn't clear :) I appreciate your inputs, as you saw some of them are already in bluerender :) Well if i do that i'll surely put a check to see if the lxf was modified (checking the timestamp), in which case i'd force the reloading.

Uhm i'm pretty sure you don't have an exact idea of how shadows work in a raytracer :P Or how complex the code behind it is :) I'm sorry but i'm not picking up the development of sunflow. I did the minimal on texture alpha support just becouse it was necessary and becouse it was a clean operation, but i'm not expanding it :) I might make some tests on texturized glass but that's all, i don't promise any result :) Sorry to disappoint you! Glad to hear your experience was explosion free :) About the error, yes you could send me the problematic lxf and i'll give it a go in debug. But first try this: i noticed that some similar errors happened to me with very old lxf files (made with old version of LDD). The solution was opening them with (current) LDD and re-saving. Some times it corrected the issue. Might help if this is your case too. About speed: is it in the proper rendering or in the "loading" phase (before opening the image window)? The rendering should be exacly the same. The loading maybe slowed a bit but i'm working on it right now. I'm switching to parallel loading, should use all the core and be about twice as fast (which will go into blueprint too!)

That was the first thing i tried, unfortunately with "fade" all bricks "shift" in grey tonality so that black looks like dark blue gray, dark blue gray like light blue gray etc. Same for all other shaded, it makes it impossible to tell the colors. I think the solution i'll go with is making submodels "movable" (just like steps) so that you can reorder them or move to other "parent" steps. Doesn't solve all problems but most of the ones you explained plus other. The first version had a toolbar like you said but looked kind of bad, it was repeated for each step and was kind of confusing. The idea of using key arrow is nice! I also like the idea of the colored bar over submodels, i already considered adding it but it was conflicting with the layout of the gui, i have to try more :)

Are you sure you're putting the instance AFTER the definition of the shader you're using? if you're using standard materials, you have to place the code i wrote AFTER them. Uh? If you mean applying textures on transparent objects, it's not possible.

ok i got it: i havent' implemented texture alpha for shaders, those one remained as they were. I implemented a texture attribute for instances. This way i can have a normal shader and apply a texture to the specific object without having a proliferation of materials (beside solving other problems). So you can use a standard material (like mat1) and apply whatever texture. The syntax is as follow: object { noinstance type generic-mesh name "Plane" points 4 0 0 0 0 1 0 1 1 0 1 0 0 triangles 2 0 3 2 0 2 1 normals none uvs vertex 0 0 0 1 1 1 1 0 } instance { name PlaneInstance geometry Plane transform { scale 5 5 5 5 translate 0 0 5 %rotatex 90 } texture c:\path\face.png shader mat37 } The result is this: Notice that object has a "noistance" attribute, it says "don't generate an object, simply memorize the geometry and let me reuse it in separated "instances" as many time as i want withour repeating all vertex etc" you can try that code with your original non-square texture, it may work. But note that in general texture should always be squared and power of two, to work interoperably with other softwares. Opengl for example require that.

i tested it after cropping at 128x128 and it worked, i didn't tested before cropping

The PNG should be a square, and possibly it may have to be a power of two, ie 128x128, 256x256, 512x512 etc. About the loading time, i'll take a look. I have a couple of ideas to make it quicker anyway. Thanks :)

Basically you're suggesting making the sun position relative to the camera instead of absolute. I already tought of that and i concord think it's necessary. Deity like no less :D Thank you! But you want gradient for the background or really as a shader to attach to plane and bricks etc? You mean that a file with IBL light was working in 0001 and not working in 0002? That's strange. Could you post a comparison? If you can pass me the offending png i can give it a try. How much slower? Can you pinpoint the step that's taking more? The startup is almost the same, strange it's slower. No actually in LDD you can put parts below zero, they just push the ground lower. In Bluerender the ground is fixed at 0, you have to change it manually as you already figured out. Maybe in future it would be automatic.

What is this new software ? :P :P PS you can preview the release here, i'll update the page later... so much to do today :(

Look like the up is wrong. It should be something like 0 1 0, i think (maybe the center has to change too?). Actually i know sunflow as much as you do (probably less by now :P) so i can't provide much help on it. I think i'll release the new version today, it will have the following changes: remembers last used folder ask before overwrite use a single scene.sc file instead of three files for setup, materials, lights scene files are not shown on the program anymore (was more confusion than anything) optional per-model scene file LDD decoration support custom decoration support For custom scene file, it will use, if exists, a file named like the lxf but with sc extension. For example if you have spaceship.lxf, it'll search for spaceship.sc (in the same folder of course) and use that. For custom decors, the syntax is as follow, where the number is the decoration ID (not the part design id): ##CHANGEDECOR 59879 c:\path\to\custom\mydecor.png As for blueprint, there's nothing that wouldn't work on Mac, but since i don't have one, i couldn't adjust all the small windows related issues and write the running scripts. If you want to try, i suggest waiting for 0002 as it will have more chance of working.

in the lights file you have to change the following line: sundir 1 1 1 you can put for example sundir -1 1 -1 for the opposite direction (note the middle one is still 1, it's the up direction). It's a vector of where the sun is coming from. I'll read the rest of the posts later :)

Now you're starting to sound like my mom :P No plans for bevels or any other geometry preprocessing. That's a HUGE amount of work actually :) Yes :) Btw, here you can download some example scenes, that cover many Sunflow functionalities. EDIT: if you have some bluerender renders with IBL i would love to see them! Actually i found out quite surprisingly that Sunflow doesn't support alpha channel for textures! I implemented a small workaround: i baked the background color into the texture. I'm also looking into implementing alpha channel support into sunflow, which doesn't look hard.

Yes, and what a feedback you gave :) Very much appreciated! Here's my response (i haven't quoted each point for quickness :P) Page setup could use top and bottom margins, as well as minimum padding between steps. Yes the page layout is kind of the weak point, more later 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. Not a bad idea actually, that of using keys! The drag rotate would be the definitive solution but also the most time consuming 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. Yes, that could be done! 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? Actually i made highlighting optional since i had negative feedback on it. I tryed to only highlight the outline some time ago but it looked not that good. Maybe i'll retry Page Layout view could use drag-select (thank you for multi-click-select). Yeah, i totally agree! There are some things to adjust in there, before it. Actually the objects in the page are organized hierarchically (for example the part box is the parent of all the single parts, which themself are boxes with the part picture and the Nx counter). This is helpful for some things (like "elastic" black borders or mass-moving), but painful for fine picking and also confusing. With drag select, i could flatten the hierarchy and still have easy mass-moving. 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. Good idea! 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. Actually the distrubution of steps is only done model-wide (and destructively :P) for all page. It really need some finer redistribution! 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. I see what you mean, there's a way around: instead of having one submodel for each step, put all submodels on the same step one after the other. That way you have: [a1,a2,a3][b1,b2,b3][c1,c2,c3][1] . In the step 1, you'll have all three subassemblies. (i know there's no functionality to move a submodel from a step to another. You have to move all the parts manually). Or you could simply delete the pages with the subassemblies :) After all some gimp retouching is always expected. 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. Thanks! Actually i would love to make it open source (i have some open source projects around), but the problem is with intellectual property. As far as i know, TLG don't want to disclose the format of their geometry database. The programs that access it are tolerated (like LDDtoPovray), but should not be usable to export the geometries. LDDtoPovray actually use a virtual file system to "covertly" feed data to POV-Ray. Open sourcing Blueprint would provide a complete library to access the data. I designed both Bluerender and Blueprint with a goal to keep the format private.

I see, that would be very easy indeed. But 88074 is the design id, or the decoration id? If it's the design id, that would put the custom decor on ALL parts with that id, which is not probably what you want. If it's the decoration id, that would work but how would you know which one you have to replace? AFAIK it's not shown on LDD, or it is? Also, many parts have more than one "decorable" sub-surface on them. For example, the minifig head has at least two: one for the face, another for the "ring" on the upper part of the head (probably has another one for the "back" face). I see, i'll see what i can do :)

That sounds like a huge amount of work you set up for me :) Decorations is mostly working, i think i'll release it soon, changeable decors also are quite easy, but I don't know how i'll implement the UI for replacement yet. About the other stuff i don't have plans to realize them honestly :) Well custom decors via tras polygons will not be necessary i think: you'll be able to choose a decor for all pieces that have texture UV mapping, which is a lot (most of them are not usable in LDD becouse they have no prints available). As for the distortion: you have to adjust the "aspect" value manually in the Setup tab (1.875 in your case). I'll automate that in the next version :) About speed, you're right, povray can be customized to be quite fast too (i'm not really an expert on the software tho, so i can't speak about how fast or how much quality). As i said i'm not trying to compete with it :) This program started as a simple experiment with sunflow. It's not in the code. It just reads diff, refl and refr (diffuse, reflection, refraction). It appears black probably becouse when there's something wrong it drops the shaders and render without any shader. Probably there's some error tracing in the console window. The code looks right, absorption.distance is accepted and should be right after color, just like you did. Try and look in the console window for errors.

The fact is that i don't know that value. The value is extracted from the LXF file, so it is dynamic. 99% of the time you want to use the LDD camera. If you want to use another setting for the camera, you can already do that (there's a commented-out example in setup.txt). I could only show how it's translated Indeed i don't need to show them and to have them separated :P i guess it was clearer, but maybe you're right

Good idea! I've created it, it's here! Add as many picture as you like! Later i'll read and reply to all other messages, thanks everybody for your interest and partecipation! :)

thanks everybody :sweet: glad you enjoyed the entry!

ahah that was unespected :D great walker, great base and a very funny story. :thumbup: I couldn't help but think this is the kind of name spaceships have in Iain Banks The Culture sci-fi saga. Is it casual or a reference?

those trans blue panels really are effective! great use! very nice model!

cool trike, effective use of parts!

awesome work!!