Closed virtualrepublic closed 8 years ago
I'm pretty sure LDraw bricks do not have UV information. LDraw bricks are generated from coordinates, they are not the same mesh data like other model types (for example, OBJ. Even though OBJ is also generated in a similar fashion as LDRaw, it has more data like faces and verts and UV maps. LDraw does not have that.) If you are positive that LDraw has UV data, I'd like to see where it is in the file so we can see how to access it. It would be great to add the LEGO logo on the studs. :)
Thanks for the fast reply. I understand now. The studs are a separate model. So it would make sense to replace it with another model. I will investigate.
Well. Not that easy because there are a lot of different type of studs. http://jc-tchang.philohome.com/manuel/part_hd.htm
This is a duplicate of #32.
Hi there,
you don't need to care about the LOGO onto the studs. You can replace some models in the LDRAW \p folder. What I did is using the normal hi-res studs and a extruded version of the LOGO. I solved the import with LDR-Importer 1.1 (which is 10 times faster than the latest version) by setting the scale to 0.1 instead of 0.05. 0.05 is perfect for the rendering but the cleanup of the mesh (what I need) will destroy the small sized LEGO logo and other details like the heads of the Mini-Figs by merging too close points. Now it looks great. I will show you some awesome renderings soon with the LEGO logo.
http://render.virtualrepublic.org/7130_Snowspeeder_002.jpg http://lego.virtualrepublic.org/issues/Studs_logo3_fixed.jpg
First of all, I want to say great work on the render! Did you use the materials that were included in the script, or make new materials?
Secondly, I'll look into the scaling issues. Maybe we need to scale after applying the cleanup instead of before. Unfortunately, since the stud with the LEGO Logo is an un-official part, we might have to package it with the script to add the option of adding the logo on studs without having to replace a file in the LDraw folders.
EDIT: I looked into the scaling issues, and you are right. Since it cleans it up after it scales it down, some mesh goes missing. I am trying to resolve this problem, but it is very difficult (mostly because I barely know any Python. :P )
Thanks. I am using the exported colors and they show up named in the specific coded like 0 for Black or 4 for Red. I need to do a Gamma Correction of the colors in the material shader of 0.45 to get the right color because MODO is working in linear color space.
The Snowspeeder model has a special brick with a picture. It's a panel in the cockpit. But the picture isn't a part of a .dat file. It seems to be poygons in MLCad. And just MLCad and LDView can show it. In LeoCAD it's missing (hole in the brick). And LDR Import can't load it, too. When I export in MLCad in "Primitives" mode it works but then I get a complete mesh of the model (no single bricks anymore) and low-res studs.
Here is an overview of the currently available studs in LDRAW. They are still unofficial and probably need cleanup. They bring tchang's work mentioned above into the LDRAW library.
Thanks for that link. I think I saw that before. I'd definitely like to add the logo on studs. It is possible, but it may not be added until 2.0 though.
Using those models will create a very complex geometry when importing complex models. I created a bevel with Primitive Generator 2 for the hi-res studs. But unfortunately you can't control the steps of the bevel in y-axis. It seems to follow the resolution in x/z-axis what will create too many sections and this will make the models unnecessarily complex.
the reason why the models get so complex is probably due to #43
@virtualrepublic Yes, the logo on the studs would add lots of geometry, and would slow things down (especially if the studs were not even seen). We may be able to use the logo (only the logo, not the stud itself because it's pre-beveled) from stud-logo3.dat in MinnieTheMoocher's link and add a bevel function within the script so that the user may determine how high quality he wants his stud to be.
Let's say you have a wall of 1.000 bricks in different colors but using the same 2x4 brick. The optimal scene would be: one master brick and the other 999 are instances using the different colors. Another complexity are the studs. If you have 10 baseplates with 50 x 50 in your scene it would make sense to have one master stud with the LEGO logo and the rest are instances on the master plate. The other 9 plates are instances of this master (incl. the stud instances). This should be the rule for all models with more than one stud. With a base plate of 50 x 50 it makes sense. But what happens when I use one master stud on a 1 x 2 brick and one instance stud and do 1.000 instance copies of this brick?
Ah, I see. So you want instancing for studs too. Good idea. I'll look into that. :)
@rioforce http://lego.virtualrepublic.org/render/7130_Snowspeeder_Normal_Studs_v03c_LEGO_RGB_Wide_4K.jpg
Check this rendering. I would not recommend to use a bevel function to keep more freedom to deal with complex models. The secret here is a rounding edge feature what fakes a bevel. I made some tests with a beveled stud what increases the scene geometry alot and it makes no difference for the result.
The "rounded edge" is the bevel. Is there another way of "rounding the edge"? It looks like you beveled his bricks before rendering. Notice the smoothness and how the light shines on the edges of all of the bricks, not only the studs. A photorealistic render requires beveling usually. But I can see how bevel would add lots of extra polys and would be a pain to work with.
of course instancing will dramatically reduce the file size, ESPECIALLY when using it for STUDS, but it will also have a big effect when applied to BRICKS and PRIMITIVES, i.e., to EVERYTHING. This will be the key feature bringing you performance and huge file size saving.
@rioforce
I did not bevel the bricks. It's a feature of the renderer creating a bevel using some kind of normal map. Creating real bevels is a nightmare and causing so much geometry that complex models like the Millennium Falcon Ultimate Collectors Edition would fail to load and render even on a machine with 32 GB RAM.
Studs instances: we have to check what happens if you create a 1 x 2 brick with one master stud and one instance and you create 1.000 instances of this brick compared to a 1 x 2 brick without a stud instance (2 normal models of the studs). In this case the software would just deal with 999 instances of one model. In the case with one stud instance the software has to handle 999 instances each using another instance of the stud. Probably you should keep it simple and just instance complete models with studs.
https://github.com/le717/LDR-Importer/issues/70#issuecomment-42192253 Ah, I didn't even think of that! Very good idea. Now you've got me inspired to go try it. :P The fake bevel doesn't seem like a thing we could do with the importer though. I may be able to hack something together, but it seems more like an addon script instead of something the importer would do.
The fake bevel is finally a feature of the 3d software. You should not care about it. If someone wants a stuf with a bevel or round logo he need to replace the stud.dat file in the \p dir of LDRAW.
Stud Instances: ignore them or add this as an optional feature. This will cause other problems with rendering the fake bevels and it creates additional hierachies. A base 50 x50 baseplate would be the plate (root) with one stud and 2.450 instances. So each brick with studs looks like this. Forget it. We need models and studs merged to one single model.
You said: We need models and studs merged to one single model. Why? Isn't a 50x50 baseplate with 1 stud object and 50*50=2500 instances better than a 50x50 baseplate with 2500 inlined stud objects ?
And if you use 3 of these baseplates, the instances also would help. You would have the geometry only 1 time, and 3 instances pointing to it, instead of having all polygones etc. DUPLICATED.
I don't see why inlining everything is done here. Can you maybe explain why it is necessary?
@virtualrepublic I can see how stud instancing would mess up your normal map, but I was thinking of making stud instancing optional anyway. It would help me in some ways, and it might help others in some ways. Unfortunately, it won't help you much, so that's why it's an option. :)
Every model with studs would have a hierachy with one master stud and 2499 instances what is much harder to deal with for the 3d software than one merged model finally. And if you have a scene with many models like this it's not that efficient like using merged models. And internally the instance of those models has to handle the whole hierachy again. And it will cause strange effects because the "Rounded Edge Width" shader has an option called: "Round Same Surface Only" I need to turn on. Otherwise there will be bevels where objects have contact. If I have a brick with separate studs there would be no bevels where the studs contact the surface.
And another problem: when I do a simulation with a collapsing LEGO house like in this example https://vimeo.com/84670417 (rendered with ARNOLD not supporting Round Edge) I definitely need merged meshes of each brick/part. My guys here also confirm that dealing with hierachies of instances for the studs might affect the performance dramatically. Let's say I have a complex model like the Millennium Falcon UCE. Due to the large number of different pieces the saving of RAM isn't an advantage when the scene performance is horrible. But anyway. Studs as instances should be an option to turn on/off.
I understand exactly what you mean now. I have had that issue before. It will definitely be an option and not set as default.
You can export the instances from Blender called "Linked Copy" with Collada what supports instances.
@virtualrepublic I had an idea on how to add the LEGO logo on studs the other week, at least in Next Gen. It is more or less a quick "if this file use this other file" swap, but it may do.
Closing this as duplicate of #32 on grounds of tracker cleanup.
The LDRAW models seem to have a texture information for mapping the LEGO logo onto the studs. This UV information should be supported by the importer because it will give us the possibility to use a picture as a bump or displacement map.