___
-
Posts
1,679 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Everything posted by ___
-
@msx80 Just in case you don't know these two links may help you a lot with implementing/exact understanding of .obj format...and there are really interesting and basically easy to understand stuff there that would enable us doing lots of things with the brick right inside its definition in .obj (like texture, color etc. - you would only have to add synonyms to the color defs in obj that would apply specified material BR and stuff like that, seems not hard to do/implement ), you just need to implement all those options in src which to me seems not that hard when someone like me who knows just a tiny bit about JAVA seem to be able doing it too after a while. https://en.wikipedia.org/wiki/Wavefront_.obj_file http://www.martinreddy.net/gfx/3d/OBJ.spec
-
Those tubes with trans red glass looks interesting...remind me kind of Aliens film and its "lab sequence".
-
Unfortunately IBL (HDR light) does not work right as it should in SunFlow : it is giving somewhat good results but HDR image is not stretched correctly and it is also oriented in wrong directions and angles for which there are no additional parameters under its settings so in the end you end up with HDR light that is giving strange results (but if one is not too demanding he can get quite interesting results anyway...kind of, let's say, "experimental" lighting ) @msx80 So I did that very simple (empty) UV mapping implementation for .obj files so one can apply modifiers and textures to it via instance object, BUT I did something not quite right cos the image is skewed and shifted to side , maybe you could look into it and possibly just repair what I forgot to see (in case you already do not have your own implementation)?
-
I do not think there is any chance BR becoming another POVRay with quantum of settings, we are talking only about bits and pieces that pushing BR abilities further to more realism yet not changing its speed in any significat way, so do not worry. I would put it like this: if now the average rendering time for some average LDD project is, let's say, 3 minutes and the same one with comparable output in POVRay would take several hours then adding some 5+ minutes to BR rendering time means literaly nothing if we get brick seams, logo-on-stud, user defined decor etc. for that, I guess you will agree...and that is the exact path we are trying to go with BR (hope I summarized it enough now ) Yea I suggested this too before as I think this could also be one of the options, but there would be need for finetuning for every single LGEO brick there is + there would be occasions where LGEO parts cannot be used, like flex hoses etc., so I don't know, I would really rather go with the .obj bricks which @msx80 already said he will do that which is super!
-
Please take no offence from what I will say now as I do not mean it like that BUT I have to tell you that besides those known factors you mentioned yourself (no brick seams and no logo-on-stud at the moment...tho things are changing from each day and once @msx80 implements what we were talking about today - .obj brick importer - those become problems of tge past instantly ) its more like you simply do not know how to light and set up your scene properly thus getting those "cartoonish" look - it needs more than trying some of the default lights that are there in scene.sc made by @msx80 If one make scene lights and setup properly he gets quite realistic scene resembling those LEGO photos of their sets from their 80's catalogues... I will show you what I mean later today or tomorrow if you will as now I have not much time... Also POVRay has much more trouble with right glass feeling (at least with trans dark blue which I am using), whereas BR makes it right with "a flick of a wrist" in contrary not even saying how extremely quick it is! + to achieve such realness as BR in POVRay you have to go up with Q settings pretty high which again rising up time needed for such render and yet it would look somewhat "surreal"/overrealistic - all in all BR fits many times better to me than POVRay when it comes to rendering my MOC Space stuff. SunFlow is quite a hidden gem @msx80 discovered for us and he deserves many big thanx on and on and on...you know.
-
How it can break LDD Eula? You do not modify LDD bricks nor its geometry as you can make those .obj bricks from LDRAW library...? Using just the position coordinates do not break anything from LDD that would be illegal cos then you come to some absurd stuff like clear polygon with my own decor being positioned into the coordinates of some concrete brick would be taken as illegal...absurd, isn't it? EDIT: + I would also like to add that actually in fact there even is not any Blender importer for LDD but on the other hand there is LDRAW importer for it (and that is what I am using, so there is not option how to get LDD file directly into Blender therefore suggesting obj bricks made in Blender would be designed from ,lxf is not quite true I guess). And YES you can combine/replace actual LDD bricks with LDRAW ones during render (so once again: not in LDD - we are using just the position matrix of the respecitve bricks for BlueRender) but as you said one needs to finetuning its size (and maybe its position too) first.
-
Yea, I know about the lack of UV mappings but as I said in my previous message here it can be done quite easily by copying and maybe slightly modifying generic-mesh UV part + I understand that the actual brick manipulation is not made in SF but in your src of BR which only you have access to, so please go for it as that would be most probably the most viable solution to our seams/logo-on-stud "problem" (that is anyone who has this skill of 3D can make a brick and then later on we can make kind of official...ehm, BR included .obj bricks that looks the best from them all, what do you think of?).
-
Animated airship in POV-ray
___ replied to Exolothon's topic in Digital LEGO: Tools, Techniques, and Projects
Cool vid - very nice and intelligent solution to those "paddlings". -
Oh, Nicola, c'mon - there already is .obj parser in SunFlow, that is of course the reason I am able loading .obj files, right? Or did I once again do not understand something? And the priority should be like: if there is an *.obj version of the brick use that one, if there is none use standard LDD brick from *.lif + I was looking into SF code why it does not support UV mapping in .obj files (file-mesh code compared to generic-mesh code which does support UV mapping) - if you try to open .obj with UV map it does not even load it, and it really looks like they simply left it out, so it should not be a problem to include the missing part into the corresponding file-mesh code...if I find myself a time I can do it, I guess.
-
I like the car design, basically modern neo-cs clone of the vehicle from LEGO 483-1.
-
Does not need to be done right now cos other things are surely much more important of course but just as a next "thing to consider" it looks very fine I guess.
-
Yea I agree that such a simple Y axis rotation camera animation add-on fro BR would be great - I am all for that! There could be just 2 parameters: 1. SPEED 2. DIRECTION OF ROTATION
-
Replacing LDD bricks with LDRAW/LGEO ones during render in BR - actually this can be done rather easily I guess, but only @msx80 can do it as the src code is part of his BR src (not SF)...basically he needs to make LDRAW parser for BR (which he already said he can do as he originally came from LDRAW), finentuning it (scaling + xyz offset - unfortunatelly this would needed to be done for every brick separatelly so it would be a lot of time consuming tiddious work) and then only replace those between one another (LDD -> LGEO) - I know this can be done as I basically did this with crater baseplate with success... Of course there would be some exceptions (a few) like flexible LDD parts: those would stay original LDD and intact...ending up mixing those two software worlds into one output (once again: such mixing can be done as I already did it myself although only with one particular brick! )
-
Quite nice build , but seeing those two legs: would they really hold the model standing still? Cos to me they seem to be there just as a aesthetic/visual part, or am I wrong?
-
OK, no problem... Yesssss, I am second that!
-
Looks beautifully
-
Hmm, that sounds interesting, so if I understood you right: if I made up my own let's say custom color brick version then brickinit.com.au (Australia?) will actually paint it for me? What are their costs? Could one design any LEGO brick or are there some limitations, like when you had to paint those airtanks yourself (why actually, what was the reason they did not paint them as well?)
-
Gee, superb! Question: how did you make that golden moon logo - is it also printed or is it a sticker? And if printed: WOW, what was the exact process...like printer, technique etc.?
-
I have no clue actually - the only one that ever came up with the concern was @msx80 (as he is the master mind behind the BR project), so I am curious as well...maybe much bigger memory usage?
-
UPDATE * renewed more realistic render of the first main photo
-
I have some other new idea of making brick seams in BR (ehm, not quite new rather the one I was suggesting before as no one actually tried to test it ), right now I am rendering something but later today I plan to try it and will post results if it would all go well...if it'd be of no use then do not await any renders.
-
Aha, got it and understood now. Of course I know about the *.g files in db.lif - and it is not that easy as you said (just rewriting number on one *.g fro another *.g, there are also *.g1, *.g2 etc. files holding UV mapping and stuff...but I understood what you mean). Well that is not bad thought and I personally like that principle BUT there are some known problems to this concept: * as of now file-mesh object does not support UV map(s) therefore anything with them would not even load * from what I said above also comes problem with bricks decorations: there would be no decors from .obj file bricks * next: who would be willing to make every single brick .obj variant??? * I am not quite sure if the process of building mesh from *.g and *.obj is the same (number of vertices/triangles can be significantly higher and there were several occasions when @msx80 said that such an exponentional increase is a problem) cos if they are different there may be a lot of additional code update needed and as this part is in BR src that only @msx80 has access to who knows if he would be willing doing it?
-
What???
-
UPDATE: @msx80 So I was finally able repair that "no more too dark glasses" side effect which makes all colors oversaturated/flat/not good...now it affects GLASS SHADERS only so any other type is intact, looks superb now! I have realized something is not right with my fix when I was constantly getting unrealistic feeling from such renders, colors without depth, all overlighted/too saturated...and then I noticed you said the first time I presented my fix that it is maybe not good to applying that code change to everything, so I change/fix it with conditional if() and with added new method to every shader (shader.type()) that returns String of the shader type - by this custom moddification I was finally able making it work as it should! BTW I also noticed some strange behaviour in some cases with my other src update for "noshadow" - for some strange reason in some situations where you place some additional object in a specific position my latest noshadow code makes areas without shadow where such shadows intersets, but strangely enough in exactly the same shadows intersection just in another placement all is fine...hmmmmm. So I think I better go at this moment with further development of "logo-on-stud" instead...or even try to play and find some possible ways for brick seams? Gee, it's extremely hot here...I hate summer!
-
Yea,that's exactly what I thought when I said my problem is most probably that I use primarily white bricks on white baseplane...I was able manage it in a way but still not satisfied + I also realize that the worse quality my latest test render have here in my testing PC is because I did not realize I am rendering using my own NOT YET FINLIZED modified SunFlow .jar that has all those latest achievement I did for BR but it got something wrong along the way so the colors are extremely, ehm, oversaturated, gee! :grin: Anyway now as I know the problem is somewhere inside my src code all I have to do is finding out where...and I already most probably know, uff. The problem appears to be in "too dar glasses fix" code I made...gotta find another way around that prob.