When Wool is above the new world height. It shows as white. Not it's color.
And, fixed! Thanks again for noticing this one. Version 2.01 is up, fixing this bug (I believe... haven't tested it myself, but the bug was pretty clear in the code) and a number of other height-related glitches.
Yet another version, 2.03. Someone suggested I simply add another slider, for the lower depth ("bottom") - d'oh, of course!
Notes: Improvement: added a "Lower depth" slider to the user interface, making depth selection obvious and easier (thanks to Adrian Alan Brown for the suggestion). Misa textures updated to 1.2.4 (Coterie, Doku, LB, and Sphax have not been updated).
So I just used Minewyas to export my Yoshi's Island model and I got a warning saying that at least one of the dimensions of my structure might exceed the size limitations of the printer.
Maybe I'm slightly blind, but I've looekd around the Shapeways site a bit and haven't found anything about the length or width limitations. Does anyone know what they are?
So I just used Minewyas to export my Yoshi's Island model and I got a warning saying that at least one of the dimensions of my structure might exceed the size limitations of the printer.
Maybe I'm slightly blind, but I've looekd around the Shapeways site a bit and haven't found anything about the length or width limitations. Does anyone know what they are?
Right, there's a limit to the size of a 3D print because of the limits of the printer itself. The stats for various materials can be found here. For colored sandstone, it's 25x38x20cm. By default, Mineways exports blocks of size 2 mm/block, so that translates into 125 x 190 blocks for the base (and 100 blocks high).
Usually if you're over this limit in some way (and you can look at the top of the .wrl file produced for more information of how much over), your model is going to cost a small fortune anyway.
One technique is to simply "go small" - make the blocks smaller than 2 mm. I like the 1 mm range, cost drops by about a factor of 8. The downside of 1 mm is that trees will snap off (the trunks are too thin to support them) and other thin features may break, too. See this section of the documentation for more. You might also find this section useful.
I have two problems. One being the vines are being rendered as a solid block when exporting for render.
Another being that if you open up the .obj in cinema4d that you exported for render the textures aren't set.
Rollback Post to RevisionRollBack
A signature was supposed to be here but your computer decided not to show it.
I have two problems. One being the vines are being rendered as a solid block when exporting for render.
Another being that if you open up the .obj in cinema4d that you exported for render the textures aren't set.
For the vines problem, that's indeed at the top of my wishlist:
Now with jungles appearing, vines really should work better. When they hang down without anything next to them, they have to be blocks, but when they're adjacent to trunks, etc., they should go flat. That said, this doesn't look quite right: a vine on a trunk will be flat, but then if it hangs in the air it will fill the "outside" block. I think the answer is to shift the vine inwards from whatever block it's in to the one it's touching.
I need to mess with this more at some point. That said, I'm hoping jmc2obj fixes this problem - they're aiming to be for rendering, and Mineways really is meant for 3D printing (it doesn't export true geometry for anything that's not a full block, for example).
With Cinema4D and OBJ files, the problem appears to be with Cinema4D's importer - mc2obj exports I believe have the same problem as Mineways' exports, C4D messes up. That's why you'll see in just about every tutorial (example here) that you should use the VRML (.wrl) export file for importing to C4D. This has its own problems (there's not a separate material for each block type, as I recall), but that's where things stand.
One person mentioned Riptide might work for C4D - there's a free version and a pro version (and the pro version has a 30-day free trial), I don't know the difference. That page is interesting, in that it points out many flaws of C4D's OBJ importer, including "On importing, most material information is lost (C4D doesn't read .mtl files)." So, my advice is to try Riptide out and let us know here whether it worked for you.
For the vines problem, that's indeed at the top of my wishlist:
Now with jungles appearing, vines really should work better. When they hang down without anything next to them, they have to be blocks, but when they're adjacent to trunks, etc., they should go flat. That said, this doesn't look quite right: a vine on a trunk will be flat, but then if it hangs in the air it will fill the "outside" block. I think the answer is to shift the vine inwards from whatever block it's in to the one it's touching.
I need to mess with this more at some point. That said, I'm hoping jmc2obj fixes this problem - they're aiming to be for rendering, and Mineways really is meant for 3D printing (it doesn't export true geometry for anything that's not a full block, for example).
With Cinema4D and OBJ files, the problem appears to be with Cinema4D's importer - mc2obj exports I believe have the same problem as Mineways' exports, C4D messes up. That's why you'll see in just about every tutorial (example here) that you should use the VRML (.wrl) export file for importing to C4D. This has its own problems (there's not a separate material for each block type, as I recall), but that's where things stand.
One person mentioned Riptide might work for C4D - there's a free version and a pro version (and the pro version has a 30-day free trial), I don't know the difference. That page is interesting, in that it points out many flaws of C4D's OBJ importer, including "On importing, most material information is lost (C4D doesn't read .mtl files)." So, my advice is to try Riptide out and let us know here whether it worked for you.
Eric
I've found a way around the c4d problem by opening it in 3dsmax and exporting it to .fbx format I think it was...
but then the alpha channels seem to mess up and I havn't found a way to fix it yet. (at least not if I'm using mineways) I've used a 1.1 jar and used mc2obj and that process worked.
Rollback Post to RevisionRollBack
A signature was supposed to be here but your computer decided not to show it.
A common complaint is, "my upload to Shapeways failed, what went wrong?" Often it is that the .wrl file, not the .zip file, was uploaded. So, now I've now made it default that only the .zip file is produced when exporting VRML for 3D printing. With only one file visible there can be no confusion for beginners.
Release notes:
New option: whether to create the model files themselves. By default, VRML printing now exports only the zip, because people often upload the wrong file to Shapeways. If you want to preview the model, just check the "Create files themselves" checkbox to keep the VRML and texture files around. Loading a new world turns off the selection and resets depths. All terrain textures now updated to 1.2.4.
(Sorry, no jungle vine fixes: my attempt caused a number of memory corruptions, so back to the drawing board.)
I've found a way around the c4d problem by opening it in 3dsmax and exporting it to .fbx format I think it was...
but then the alpha channels seem to mess up and I havn't found a way to fix it yet. (at least not if I'm using mineways) I've used a 1.1 jar and used mc2obj and that process worked.
Hmmm, I wonder what mc2obj is doing that I'm not. I've looked at their material file, it didn't seem all that different. Mc2obj does produce a ton of separate textures, which is actually a good thing when rendering; for 3D printing I need a single texture file, that's all the 3d printer accepts, so I'm stuck with that format.
If you figure anything out and it's an easy enough fix on my end, I'm happy to make the change.
Hmmm, I wonder what mc2obj is doing that I'm not. I've looked at their material file, it didn't seem all that different. Mc2obj does produce a ton of separate textures, which is actually a good thing when rendering; for 3D printing I need a single texture file, that's all the 3d printer accepts, so I'm stuck with that format.
If you figure anything out and it's an easy enough fix on my end, I'm happy to make the change.
Then although it would be a big overhaul do you think you can have the export for rendering use separate textures and have the 3D printing export have the current way?
I just want a solution for making minecraft sets without having to go through and make every-single block in C4d. Appreciate the help.
Rollback Post to RevisionRollBack
A signature was supposed to be here but your computer decided not to show it.
Then although it would be a big overhaul do you think you can have the export for rendering use separate textures and have the 3D printing export have the current way?
I don't think I'll make such a major change, to be honest - my focus really is 3d printing, and I'm hoping jmc2obj will be the best solution for rendering export someday. Perhaps while waiting for them to catch up you could give Riptide a try (it's free) and see how that goes?
I don't think I'll make such a major change, to be honest - my focus really is 3d printing, and I'm hoping jmc2obj will be the best solution for rendering export someday. Perhaps while waiting for them to catch up you could give Riptide a try (it's free) and see how that goes?
Eric
I would but I can't seem to get my C4D to recognize plugins. I have it installed in the correct spot but its just not working. I have r13.
Rollback Post to RevisionRollBack
A signature was supposed to be here but your computer decided not to show it.
When I put my minecraft world into Autodesk, why is there darker textured outlines for each block after render when a distance away?
Here is a picture of what I mean: http://i.imgur.com/9F9Ye.jpg
When I put my minecraft world into Autodesk, why is there darker textured outlines for each block after render when a distance away?
Here is a picture of what I mean: http://i.imgur.com/9F9Ye.jpg
I believe what is happening is that they're using some form of mipmapping on the tiles. Basically, I think they're sampling off the edges of the textures I set up. This is one reason mc2obj is probably better for rendering (though the UI is bad): by putting every block face into a separate texture, that exporter doesn't then have to worry about samples from one texture bleeding into another.
It seems to me there should be some control on what happens when a texture is far away or on-edge (which is when mipmapping or other sampling techniques kick in). Sampling a texture like this is called "minification" (where there are more texture texels than there are pixels being covered). But, I'm clueless about how the various renderers allow control of texture sampling and what should be done.
Googling a bit, I found this: right, you definitely do not want to use pyramidal sampling (mipmapping, essentially), summed area will not have the problem of sampling outside the texture tile. So use summed area.
By "into Autodesk", do you mean Maya, MAX, or some other product? Autodesk has a bunch of packages for rendering. Anyway, I'm guessing Maya has some similar way to change texture sampling to something high quality, like summed area or elliptical weighted average or whatever. Find that control and see if it fixes your problem (and let me know - I'm knowledgeable about rendering, but not about the various packages out there).
Hmmm, weird one, thanks; I'll look into it.
And, fixed! Thanks again for noticing this one. Version 2.01 is up, fixing this bug (I believe... haven't tested it myself, but the bug was pretty clear in the code) and a number of other height-related glitches.
Updated to Minecraft 1.2.4: added circle brick, different wood planks, and sandstone variants. Fix: swap spruce and birch saplings.
In other news, I found this nice little page summarizing the exporter programs out there, including one I hadn't seen before.
Notes: Improvement: added a "Lower depth" slider to the user interface, making depth selection obvious and easier (thanks to Adrian Alan Brown for the suggestion). Misa textures updated to 1.2.4 (Coterie, Doku, LB, and Sphax have not been updated).
Maybe I'm slightly blind, but I've looekd around the Shapeways site a bit and haven't found anything about the length or width limitations. Does anyone know what they are?
Right, there's a limit to the size of a 3D print because of the limits of the printer itself. The stats for various materials can be found here. For colored sandstone, it's 25x38x20cm. By default, Mineways exports blocks of size 2 mm/block, so that translates into 125 x 190 blocks for the base (and 100 blocks high).
Usually if you're over this limit in some way (and you can look at the top of the .wrl file produced for more information of how much over), your model is going to cost a small fortune anyway.
One technique is to simply "go small" - make the blocks smaller than 2 mm. I like the 1 mm range, cost drops by about a factor of 8. The downside of 1 mm is that trees will snap off (the trunks are too thin to support them) and other thin features may break, too. See this section of the documentation for more. You might also find this section useful.
Eric
Another being that if you open up the .obj in cinema4d that you exported for render the textures aren't set.
For the vines problem, that's indeed at the top of my wishlist:
I need to mess with this more at some point. That said, I'm hoping jmc2obj fixes this problem - they're aiming to be for rendering, and Mineways really is meant for 3D printing (it doesn't export true geometry for anything that's not a full block, for example).
With Cinema4D and OBJ files, the problem appears to be with Cinema4D's importer - mc2obj exports I believe have the same problem as Mineways' exports, C4D messes up. That's why you'll see in just about every tutorial (example here) that you should use the VRML (.wrl) export file for importing to C4D. This has its own problems (there's not a separate material for each block type, as I recall), but that's where things stand.
One person mentioned Riptide might work for C4D - there's a free version and a pro version (and the pro version has a 30-day free trial), I don't know the difference. That page is interesting, in that it points out many flaws of C4D's OBJ importer, including "On importing, most material information is lost (C4D doesn't read .mtl files)." So, my advice is to try Riptide out and let us know here whether it worked for you.
Eric
I've found a way around the c4d problem by opening it in 3dsmax and exporting it to .fbx format I think it was...
but then the alpha channels seem to mess up and I havn't found a way to fix it yet. (at least not if I'm using mineways) I've used a 1.1 jar and used mc2obj and that process worked.
A common complaint is, "my upload to Shapeways failed, what went wrong?" Often it is that the .wrl file, not the .zip file, was uploaded. So, now I've now made it default that only the .zip file is produced when exporting VRML for 3D printing. With only one file visible there can be no confusion for beginners.
Release notes:
New option: whether to create the model files themselves. By default, VRML printing now exports only the zip, because people often upload the wrong file to Shapeways. If you want to preview the model, just check the "Create files themselves" checkbox to keep the VRML and texture files around. Loading a new world turns off the selection and resets depths. All terrain textures now updated to 1.2.4.
(Sorry, no jungle vine fixes: my attempt caused a number of memory corruptions, so back to the drawing board.)
Coming someday soon: the Northwestern University campus will be printed in 3D from a Minecraft model.
In the meantime, an image made with Cinema4D and Mineways (click on link for larger version):
Hmmm, I wonder what mc2obj is doing that I'm not. I've looked at their material file, it didn't seem all that different. Mc2obj does produce a ton of separate textures, which is actually a good thing when rendering; for 3D printing I need a single texture file, that's all the 3d printer accepts, so I'm stuck with that format.
If you figure anything out and it's an easy enough fix on my end, I'm happy to make the change.
Then although it would be a big overhaul do you think you can have the export for rendering use separate textures and have the 3D printing export have the current way?
I just want a solution for making minecraft sets without having to go through and make every-single block in C4d. Appreciate the help.
I don't think I'll make such a major change, to be honest - my focus really is 3d printing, and I'm hoping jmc2obj will be the best solution for rendering export someday. Perhaps while waiting for them to catch up you could give Riptide a try (it's free) and see how that goes?
Eric
I would but I can't seem to get my C4D to recognize plugins. I have it installed in the correct spot but its just not working. I have r13.
Here is a picture of what I mean: http://i.imgur.com/9F9Ye.jpg
I believe what is happening is that they're using some form of mipmapping on the tiles. Basically, I think they're sampling off the edges of the textures I set up. This is one reason mc2obj is probably better for rendering (though the UI is bad): by putting every block face into a separate texture, that exporter doesn't then have to worry about samples from one texture bleeding into another.
It seems to me there should be some control on what happens when a texture is far away or on-edge (which is when mipmapping or other sampling techniques kick in). Sampling a texture like this is called "minification" (where there are more texture texels than there are pixels being covered). But, I'm clueless about how the various renderers allow control of texture sampling and what should be done.
Googling a bit, I found this: right, you definitely do not want to use pyramidal sampling (mipmapping, essentially), summed area will not have the problem of sampling outside the texture tile. So use summed area.
By "into Autodesk", do you mean Maya, MAX, or some other product? Autodesk has a bunch of packages for rendering. Anyway, I'm guessing Maya has some similar way to change texture sampling to something high quality, like summed area or elliptical weighted average or whatever. Find that control and see if it fixes your problem (and let me know - I'm knowledgeable about rendering, but not about the various packages out there).
well when i rendered it the torches had a white box...