Blender BLB Exporter [v2.0.0]

Author Topic: Blender BLB Exporter [v2.0.0]  (Read 17543 times)

BLBs do not support such a feature as far as I know. If they do, please give me a link to a brick that does it.
how do I paint the brick a certain color then? if I set it to a diffuse color it will stay that color when i plant it.

BLBs do not support such a feature as far as I know. If they do, please give me a link to a brick that does it.
uhhh

like, a ton of bricks? take a look at my camera brick for example (its on blg). note how the base recolors to a shade of the brick color.

leetzero's guide to brick making explains how the naming system for colors works. google leetlegacy brickmaking for a link. some pictures at the bottom of the guide also show bricks with shading

@perry you cant tint the sprayed color with a different color though. just tint it darker or lighter

uhhh

like, a ton of bricks? take a look at my camera brick for example (its on blg). note how the base recolors to a shade of the brick color.

leetzero's guide to brick making explains how the naming system for colors works. google leetlegacy brickmaking for a link. some pictures at the bottom of the guide also show bricks with shading
Sorry, you're absolutely right. I just completely forgot that was a thing even though I've extensively used it in the past. I will be updating the add-on soon™.

Additive colors:
  • Object colors: gray color and negative alpha.
  • Material colors: You can't specify a negative alpha in the Blender UI so I will have add in a feature for this.
  • Vertex colors: gray color and negative alpha in the layer name.

Subtractive colors:
  • Object colors: negative gray color and negative alpha.
  • Material colors: You can't specify negative values for colors in the Blender UI so I will have add in a feature for this.
  • Vertex colors: You can't specify negative values for colors in the Blender UI so I will have add in a feature for this.

@perry you cant tint the sprayed color with a different color though. just tint it darker or lighter
Actually you can by using a non-gray color and negative alpha. For example a red color with negative alpha colored blue in-game produces violet. Or a yellow color where the red component is negative with negative alpha is actually green in-game, except when colored white or blue it turns cyan. There's probably a way to figure out what combinations produce what colors but I honestly don't see how this is helpful. I guess it technically allows the user to define two colors for a brick with a single spray can color.
« Last Edit: November 13, 2016, 02:47:10 AM by Demian »

I will be updating the add-on soon™.

Joke's on you! You can't trademark Valve time!

Version 1.1.0 released

Download Latest Version · Full Change Log & Update Instructions

Minor tweaks and fixes, added support for additive and subtractive coloring with materials and vertex colors. Readme is now prettier with a table of contents and internal linking.

Version 1.1.0 released

Download Latest Version · Full Change Log & Update Instructions

Minor tweaks and fixes, added support for additive and subtractive coloring with materials and vertex colors. Readme is now prettier with a table of contents and internal linking.
Awesome!

Do you think you could show us a picture of how to set up hierarchy properly for exporting Multiple Bricks by Group?
I'm assuming that it goes like Group1 > BOUNDS0, COLLISION0, MESH0       Group2 > BOUNDS1, COLLISION1, MESH1

maybe instead of using material colors, use the material name alongside its color?

I made a small brick pack using this, check it out!
https://forum.blockland.us/index.php?topic=304644.0

This actually works surprisingly well, with almost no errors anywhere. One issue I notice is that the height of the brick will be a little weird (sometimes it'll be a little higher off the ground, sometimes it will be a little inside the ground). What defines the very bottom of the brick? Is it the location of the BOUNDS, the COLLISION or the brick mesh itself?

I made a small brick pack using this, check it out!
https://forum.blockland.us/index.php?topic=304644.0

This actually works surprisingly well, with almost no errors anywhere. One issue I notice is that the height of the brick will be a little weird (sometimes it'll be a little higher off the ground, sometimes it will be a little inside the ground). What defines the very bottom of the brick? Is it the location of the BOUNDS, the COLLISION or the brick mesh itself?
The BOUNDS box determines the exact size of the brick. a brick's mesh can extend outside of the BOUNDS box - the COLLISION cannot (well it can but it will be glitchy)

Awesome!

Do you think you could show us a picture of how to set up hierarchy properly for exporting Multiple Bricks by Group?
I'm assuming that it goes like Group1 > BOUNDS0, COLLISION0, MESH0       Group2 > BOUNDS1, COLLISION1, MESH1
There is no hierarchy anywhere. Each group is a new brick and can contain whatever just like with single brick export. One object can be in multiple groups if you so wish which is useful for doors, for example, where the size of the brick should not change between the open and closed states.

maybe instead of using material colors, use the material name alongside its color?
The material name, if it is one of the valid brick texture names (BOTTOMEDGE, BOTTOMLOOP, RAMP, SIDE, TOP), is used. Otherwise it is ignored. (Unless it contains "blank", see the readme.) As I'm typing this I realize that I have forgotten "PRINT".

The BOUNDS box determines the exact size of the brick. a brick's mesh can extend outside of the BOUNDS box - the COLLISION cannot (well it can but it will be glitchy)
This is correct. The bottom face of the bounds object is the bottom plane or "ground" of the brick.

There is no hierarchy anywhere. Each group is a new brick and can contain whatever just like with single brick export. One object can be in multiple groups if you so wish which is useful for doors, for example, where the size of the brick should not change between the open and closed states.

The material name, if it is one of the valid brick texture names (BOTTOMEDGE, BOTTOMLOOP, RAMP, SIDE, TOP), is used. Otherwise it is ignored. (Unless it contains "blank", see the readme.) As I'm typing this I realize that I have forgotten "PRINT".

This is correct. The bottom face of the bounds object is the bottom plane or "ground" of the brick.
Alright this clarifies things. If I want to specify multiple collision boxes, would i do like, COLLISION0 and COLLISION1 etc? Also, i've tried naming a top texture to 'TOP' and for some reason when I add it in-game the top print is actually a SIDE texture. Does this have to do with the naming, rotation, or maybe do I need to UV map it properly?

Alright this clarifies things. If I want to specify multiple collision boxes, would i do like, COLLISION0 and COLLISION1 etc?
Nope. You definitely do not want to do that because collision1 is not a valid token. See Definition Tokens for details on how to use them. COLLISION 1 and COLLISION 2 would be valid ways to define collision objects but the preferred method is to simply the name the object "collision" and duplicate it. Blender will add the index (e.g. "collision.003") to the end but that is automatically removed. Although you've given me an idea to improve this system for greater legacy support, thanks!

Also, i've tried naming a top texture to 'TOP' and for some reason when I add it in-game the top print is actually a SIDE texture. Does this have to do with the naming, rotation, or maybe do I need to UV map it properly?
That is certainly odd. If the material name is "top" (case insensitive) it should use the top brick texture on the assigned faces. I've just tested this and it certainly does not work, I must have broken it at some point. Regardless this doesn't really matter yet because using brick textures doesn't really help because the UVs are not calculated so you couldn't see the texture anyway. I'm currently working on the UV calculation.

Tried it out, it works pretty well.
However you should trim the automatic color generation too.


However you should trim the automatic color generation too.

Indeed. I'm starting to think that 6 decimal places is good enough for everything and just rounding all the values.