___
Eurobricks Counts-
Posts
1,679 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Everything posted by ___
-
I guess he should reinstal it right away as it looks like broken JAVA instalation. If you are on Windows, after uninstaling also restart your machine and only then instal your JAVA again, like: uninstal JAVA restart your PC instal JAVA
-
This is one nice build!
- 14 replies
-
- Classic Space
- Space Marine
-
(and 1 more)
Tagged with:
-
Indeed, as you may know I am not Java programmer, I am Adobe FLASH AS2 mainly so this was just hypothetical hoping you will understand that I was trying to be as much helpful as possible having thought you understand it and just change it to suit your needs...nevermind BTW: I think even with the most complicated piece of code many times it needs just one "final" line that simply strips concrete object from the processing, like there have to be some point where the code apply some other part of functions/code that actually make shadows etc. so I thought simple "if" would be enough to tell the code to avoid respective objects...ah, whatever. OK, would be great if the texturized glass part work I do not agree: many times I change something in the respective .lxf and if it would not reread it everytime then it would not render the last version, like with the .lxf still selected in BR I open LDD, do some modifications, save and then hit Render on BR.
-
Or even better - to somewhat standardizing such behavior - let's add 3 new attributes for shader or object inspired in POVRAY like: shader { noshadow noreflections noimage ... } object { noshadow noreflections noimage ... } I guess they are selfexplanatory, anyway: noshadow - shader/object does not cast shadow noreflections - shader/object does not cast its reflections on other objects noimage - shader/object is casting shadow and reflections (unless previous attributes are present) but the object itself is not visible
-
OK, so now it works (thanx @ msx80) BUT not with the glass shader + also according to SunFlow PDF there should also be support in "trace-depths{}" statement for attribute "trans" (which is trans 10 be default so that said THERE DEFFINITELY SHOULD BE COMPLETE TRANSPARENCY POSSIBLE in SunFlow, right? ) but when I set it there nothing is rendered at all... EDIT: I just realized they are only nr. of bounces not the amount of transparency, ah... This exploration is so exciting, every minute I found something new even things that was said do not exist like complete mesh/shader transparency...well, there is one like this: shader { name trns type glass color 1 1 1 eta 1 } This way you achieve completely transparent object...ehm, the only disadvantage is that it still cast shadows, except that it seems to be OK (@msx80: could you also implement shadow transparency for completely transparent object like this, please? ) I guess simple programmatic solution would be something like this: if((shader.type == "glass") && (shader.glass.color == 1 1 1) && (shader.glass.eta == 1)) { shadows.casting = false; }
-
Yes, of course - I applied it exactly as in your preview... Oh, that is not good cos then I am done with my "polygon trans decor" trick...
-
That does not work at all, all I got is completely black rectangle Could it be that you have some new code in the BR version you are testing it yourself that is not in the latest v2...maybe? Besides if there is need to also have a shader applied on the instance how it can have transparent bg when there is no option how to make a shader color value transparent?
-
Aha, underestood - gonna try it right away... Did not know that as I was not doing some universally usable ones, just for my needs where I need approximate size of the target shape (be it rectangle or any other) to lay my design right and if it were for LDD only then I hard resized it to strict deformated 128x128 but of course that would work in everywhere just like you said BUT the case is I wanted to avoid permanent resizing back to its right dimensions everytime I want change something in the design or graphic
-
Interesting enough, so please could you show me your exact syntax of implementation (that is mesh object code + shader code)? Better said: made just simple rectangle (4 sides if you do not know ...not box, just 2D rectangle) and try to apply it there cos that is how I am doing it Actualy this the block of my code: # shader { name cs type diffuse texture Z:/_LEGO_/__MOC__/691518/2466p90.png } # object { shader cs transform { scale 5 5 5 5 translate 0 0 5 %rotatex 90 } 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 } And here how it actually look:
-
Ee, no, not this one, cos this is my file for my technique of "trans polygon decors" in POVRAY If it'd be for LDD decors change then it should be exactly 128x128 as that is the decors size from db.lif Anyway what have its size to do with the fact the transparency still do not work? Or am I missing something? BTW I tested also this kind of size with LDD replacement decors and all was working fine so... Did its transparency work for you? If so could you please show me your exact syntax of implementation (that is mesh object code + shader code)? If you are on 64bit OS shouldn't that Java installer select its 64bit version automatically by default?
-
Almost: NOT THE SUN, cos like in reality sun is still on its place independent of your camera position, I am talking specificslly about SPHERICAL and DIRECTIONAL lights only: those needs to correspond to actual camera view so when I want move them to right side of the camera they have to be on right and not on the right side of the front side of the LDD plane Sorry, I was simply smashed by the fact v2 is here so I go nuts for a while trying to be funny... Shader as I mean it as a counter part to normal color and textures options we already have, such shader can be then applied to any mesh, so if I wanted infi ite background I would make L ramp mesh and apply thet gradient and yet I can use it as a surface on anything else, therefore mainly SHADER, yes ...but if you can also make some kind og gradient background besides the gradient shader then please go for it as well! As for the IBL Light: strangely enough for some reason it works now (maybe I had some errors in my script in .sc) And as for the .png problem, here it is for you to test it yourself: Well, when I have all set and hit RENDER button it seems like the parser fights with every single brick like 0,5 seconds so the time to actual pop up of the rendering image window is quite long like 1 minute with bigger model whereas in v1 it was like "swooooosh!", almost immediately...I do not know maybe you left in you code some part that is not necessirily repetitive with every brick and that part slowing it down? Now that is not tge case: when you have such .lxf where its base was lowered to negative Y and you move your camera in LDD quite to the bottom so you look at your model from stright front side you will see MOST OF THE MODEL HANGS IN THE AIR and just the lowest brick sits on the plane, so I rather suggest the trick I write in my post above that fix it. But many times you even need to cut (CTRL+C) or even delete for a second that lowest brick so all your model got down to the y0 plane and then bring the previously cutted/deleted brick back
-
Firstly: being glad my advice helped you Secondly: I do not know if it can be considered as a LDD bug (but probably it is), anyway I am dealing with this LDD behaviour from the first moment I started working with it (like 4 years ago), maybe you could post it in LDD bugs subforum?
-
SUGGESTIONS: * missing LDD decorations - when there is missing decoration in LDD (ehm, for whatever reason...as it is considered illegal on this forum I cannot talk about it publicly here but can explain it to you over PM if you'd be interested,no problem ) rendering stops, if it is possible it should simply continue without any decoration on the respective brick (this way it goes very well in POVRAY) - now the practice with BlueRender is such that it just stops with error popup.
-
No, the problem is actually in your .lxf file where you probably added some brick to the lower most one so the whole scene in LDD got lower than y0 (that is into negative Y) but you would not see it until you render it or until you go to LDd open the .lxf CTRL+A (selecting all your bricks of the model) and slightly move them together a tiny bit - that way your LDD model got back so the lowest brick will be positioned correctly to y0
-
v2 problems: IBL Light do not work .png with trans bg still renders as opaque white (high quality 32bit with full range colors incl. alpha channel, not those common 8bit with limited number of colors) for some reason v2 takes much longer to start rendering compared to v1
-
Gee, sorry, I meant BlueRender, of course. Gonna play with the new version now...thanx a lot!
-
SUGGESTIONS: * correct lights positioning - it should be positioned from BlueRay camera point-of-view, not from LDD original front side, cos then when you have your camera look lets say from behind and set your lights has to be "-10 0 0" then it actually move them in exact opposite direction to "10 0 0" cos it has locked its XYZ axes to front LDD view still which is wrong + of course not even saying they are not straight opposite values but it rather add some more degrees to it so it is in fact absolutely not possible to achieve quite simple lights placement as you may see I guess basically something similar you did with the camera transformation using %LDDCAMERA% but this time it should be upon actual BlueRender already transformed camera position where light "0 0 0" = transformed camera "0 0 0" position...and I think this one feature is the most important for now * simple color gradient shader - allowing us having smooth color transition at least between two defined colors, that'd be great...and I know you can do it as you already proved your almost deity-like...or something * rotation for IBL Lights - for correction of alignment of the HDR angle for such cases where simple "flipping" does not help
-
OK, here are some clues for you all: light { # type of light used type sunsky # sun positioning on axes X Y Z # 0 -1 0 = sun is literaly underground # 0 0 0 = model sits on sun surface # 0 1 0 = sun is above model in the sky (normal behavior) up 0 1 0 # have not much clue actually, really east 1 0 0 # placement of the sun ergo length and direction of the shadows and therefore also whole scene colorisation- like is it morning sun? evening sun? winter sun? summer sun? sundir 1 1 1 # power of the sunshine: lower = more shadows and darker all around, higher = kind of (over)saturation effect turbidity 4 # the more samples the more quality of shadows and the illumination itself samples 32 }
-
THAT IS ABSOLUTELY FANTASTIC - and I am even happier seeing my suggestions were any useful...and it is exactly as I would do it myself, simply perfect (you even applied the logic I intended to suggest regarding the .sc naming, super! ) - so now being as your mother I can clearly say: YOU ARE NOT GOOD, YOU ARE THE BEST! :laugh: :thumbup: I am affraid that is not the case as I really tried all thinkable options... It looks more like there could be rotation option for the ibl light (could it be done programmatically?) EDIT: Oh, and one more thing: please, if you can, include also simple .log output of the imported .lxf bricks as we were speaking before, could you? Like it would make "spaceship.log" in the .lxf folder with every render (rewritten everytime without warning), you know similar to .pov output where one can search for the respective brick with all its attributes (colorID, decorationID, MATRIX etc...)
-
PROBLEM: * IBL light (HDR image) - for some reason whatever I do I am still getting wrongly oriented HDR or at least I guess so. Using "standard" settings for ibl positioning in SunFlow (according to one of the tut files) like: ... center 0 -1 0 up 0 0 1 lock true ... ...but as you may see the picture seems to be wrong (and you can bet I really did try all possible combinations, even the absurd ones ): HDR preview ibl result
-
thanx - when I was doing the "planting" I did not think about the types of the fluora used, I just grab the first one...ehm, basically all the ones I have found Monorail...hmm, if I implement it it must be something TOTALY DIFFERENT in design from what I saw to this they cos all MOCs that were trying to be monorail clones were just that: almost exact LEGO monorail clones just with different colors and a small number of different bricks but whole concept was just copied from LEGO monorail (unitA + motor in middle + unitB) therefore I find all those MOCs quite unoriginal and unintersting frankly , so who knows? I see what and if I can do about it sometime later...anyway thank you for the suggestion.
-
Could you post your render, just a preview to let us see what exactly you mean by that...?
-
Sorry I didn't notice this question first time, so here it is (you can write this in whatever of those 3 .txt files but for msx80 usage we use the way he made it...therefore put this into Lights.txt or the Lights tab in BlueRender): light { type ibl # BEWARE: notice that for it to work you have to MANUALY CHANGE all "\" in the path to "/", also do not use any quotation image Z:/somePath/myImage.hdr # this moves your HDR image on x/y/z axes, changing it changes how/what part of the image actualy giving you the light center 0 1 0 # do not change this part, just leave it as it is! up 0 0 1 lock true # the higher the samples the better lighting/shadows samples 200 } P.S.: if you put it in the Lights.txt file then it will be loaded everytime you run BlueRender, if you just put it in the Lights tab then it will be lost as soon as you close BlueRender.
-
Thanx tho they were just a quick renders to show the difference... I know about that option but I would like to solve it in BlueRender itself without any other additional graphical "hokus-pokus" if you understand me...as this should be done straight away in the rendering tool/engine BTW I think there is something wrong with the HDR image or the IBL light type cos the image seems not being right, looks like zoomed a lot to me, hm...