Pictures for woodsspeople :o)
- Thread starter metouto
- Start date
Cool! We love it! It's a kind of simple plant, but it is just the start. Can you let us know if you had any trouble or if we can help with anything?
Officially taking over this task from metouto, who gave it a try for us, showed it would work and promises to give advice as needed (thanks metouto!!). Two main questions at this point for Cervator and the team:
1. What would happen if the image was bigger than 16x16 for one block? How would TS deal with that? What is a reasonable maximum to retain the blocky look?
2. If we wanted to make a tall billboard plant that took up two vertical blocks, how would we do that?
1. What would happen if the image was bigger than 16x16 for one block? How would TS deal with that? What is a reasonable maximum to retain the blocky look?
2. If we wanted to make a tall billboard plant that took up two vertical blocks, how would we do that?
I think the main trick about the resolution would be creating a secondary image manifest for high-res blocks. As the current 16x16 pixel block images are loaded they're merged into a single image, which is then fed to the OpenGL / the video card for rendering. It does that by painting a 16x16 section from the appropriate location on the big image to the screen.
So if you were to make, say, 32x32 higher res plant textures only a quarter of that would actually paint (not to mention all the coordinates would probably be off). Or so is my quick theory, anyway, still not a 3D wizard
A second higher res image manifest would work the exact same way, just with the larger numbers.
What I don't know is how we'd differentiate between the two different manifests during loading and rendering. That might take a little work to prep.
Or maybe we can make the coordinates dynamic instead of only every 16x16 - then perhaps we could have everything in the same manifest. That would also open up the potential of, say, 32x64 two-block textures for larger billboard plants.
Breaking two-block high plants might take some work - could be the same system as trees that know what blocks they're made up by, but in a smaller version . Which isn't built yet either and would likely involve entities. Maybe two-block billboards could be handled in a more simple fashion.
I'd need to refer to the experts for more details and an idea of how much work this would be to implement.
In the meantime - I think you might be able to cheat by stitching a single high res plant together by using multiple (non-billboard) blocks, then putting them together like a small puzzle. Not very elegant, but it could yield an idea of what it would look like in-game
I might have pushed this angle prematurely vs. implementation level
So if you were to make, say, 32x32 higher res plant textures only a quarter of that would actually paint (not to mention all the coordinates would probably be off). Or so is my quick theory, anyway, still not a 3D wizard
A second higher res image manifest would work the exact same way, just with the larger numbers.
What I don't know is how we'd differentiate between the two different manifests during loading and rendering. That might take a little work to prep.
Or maybe we can make the coordinates dynamic instead of only every 16x16 - then perhaps we could have everything in the same manifest. That would also open up the potential of, say, 32x64 two-block textures for larger billboard plants.
Breaking two-block high plants might take some work - could be the same system as trees that know what blocks they're made up by, but in a smaller version . Which isn't built yet either and would likely involve entities. Maybe two-block billboards could be handled in a more simple fashion.
I'd need to refer to the experts for more details and an idea of how much work this would be to implement.
In the meantime - I think you might be able to cheat by stitching a single high res plant together by using multiple (non-billboard) blocks, then putting them together like a small puzzle. Not very elegant, but it could yield an idea of what it would look like in-game
I might have pushed this angle prematurely vs. implementation level
Wow, sounds like it is better to do what we can with 16x16 for the moment! Can always revisit later. Will keep high-res images for later use.
Creating a texture atlas (combining together the textures for different blocks into a single texture) is a critical performance improvement as it allows the world to be rendered in as few passes as possible. If/when we increase the number of available block ids, the texture atlas will be the next bottleneck, so I'm a bit reluctant to introduce higher-res textures into the mix.
The way things are set up, each block shape specifies texture coordinates in terms of a single 16x16 texture for each side, and when you specify a block the block shape is modified to refer to the correct coordinates in the texture atlas. Obviously can just map those ranges to larger parts of the texture atlas if desirable.
The way things are set up, each block shape specifies texture coordinates in terms of a single 16x16 texture for each side, and when you specify a block the block shape is modified to refer to the correct coordinates in the texture atlas. Obviously can just map those ranges to larger parts of the texture atlas if desirable.
What we should probably do is introduce some simple attachment information into the blocks themselves, and have the world (or some flavor of system) know that when a block is no longer connected by any of its attachment sides it should be destroyed - basically a more generic form of how grass is destroyed when the block below it is removed at the moment. This could be applied to things like torches, cacti and multi-block plants - just a generally useful intermediate between simple blocks and a full compound-block entity.
On the texture atlas - there are modern FPSes that probably have more detail in a single texture than we'll ever have in the entire atlas, so will it actually be a bottleneck? I figure GPU memory usage for texture storage will always be tiny in comparison. Unless it factors in somehow when we're painting these tiny swatches on the terrain so many times?
For "simple" plants that always have the same shape (not the super duper fancy growth simulator that might power trees with custom shapes involved) could we use a mixture of the grass destruction check + temp entity from damaging a block that additionally has a plant component of some sort attached so we'll know a little about what to expect (find my second block either below or above current block, then destroy it too) and what to drop if anything (my plant type drops seeds of x)? That might also allow for more advanced "deconstruction" of the plant for something like alchemy, where you could engage with the plant in a few different ways (snip, cut, prune, poke..) with different results, without storing permanent entities?
Unless we don't really need entities at all for that, unsure.
For "simple" plants that always have the same shape (not the super duper fancy growth simulator that might power trees with custom shapes involved) could we use a mixture of the grass destruction check + temp entity from damaging a block that additionally has a plant component of some sort attached so we'll know a little about what to expect (find my second block either below or above current block, then destroy it too) and what to drop if anything (my plant type drops seeds of x)? That might also allow for more advanced "deconstruction" of the plant for something like alchemy, where you could engage with the plant in a few different ways (snip, cut, prune, poke..) with different results, without storing permanent entities?
Unless we don't really need entities at all for that, unsure.
Just to make sure you know, the PlantStudio software does output 3D models in for example OBJ format which I see you are using for the monkey head. So we could use full models instead of billboards for plants if you wanted that. Also, my husband ported the non-GUI parts of the PS code to Java some time ago, so you could also have non-tree plants actually growing in-game and interactable-with, if you wanted it. I had pruning in the version he ported, I think. It would take some serious integration work to draw that code in and make it work, and I don't have time for it (and may never have that much time) but the potential is available and we are amenable to it. (Actually he has been bugging me to mention that for some time, he keep saying why not have the plants grow in the game?) However I'm not sure detailed 3d models of growing plants is in keeping with the blocky nature of the game.
Interesting
Be hard to say how it would work without seeing it, but I couldsee imagine frail and flimsy plants growing in-game in detailed 3D possibly without clashing with the blockiness. It is more super detailed 3D trees that might look funny, I think. Depends a bit on exactly how said 3D plants look, and perhaps especially on how the engine handles the more detailed models . Would be hilarious to lag the world to death by adding some plants if it can handle a hundred creatures running around no problem
Be hard to say how it would work without seeing it, but I could
gave up on rendering the plant objects for now, thought I might be able to get some simple results with limited knowledge, and while I managed to have the code run with a custom plant obj file without errors it didn't render anything so to be revisited later...
reminds me of a sticker I had on my moppet:
don't follow me, I don't know where I'm going either
reminds me of a sticker I had on my moppet:
don't follow me, I don't know where I'm going either
We wrote that OBJ exporter a long time ago and I wonder if the OBJ format has changed. PS also exports other 3D formats (dxf I think) and those might work better. Back in the day I would have known all about it. When I get a minute I can try to do something with Blender. Many things to do ...
well you might be right, the obj file I got to work was one I exported from blender after unwrapping it. But as i said, still didn't give me the effect I hoped for. Also sick as dog so I might have overlooked something, but as stated before, this certainly ain't my field of expertise either. I'd like to invest time I have in maintaining / improving what I made so far, I would need to redo some blender tutorials etc to better understand the whole process to get something working, but it's not something I label as cancelled, just postponed.One thing that still escapes me so far is the dimensions of the plant and how to make it fit the size of 1 block for example. But that's all lack of knowledge / brainpower.
The plantstudio really is a nice tool, like Cervator suggested before, it would be a nice project to incorporate it into Terasology, letting people decide what plants to use etc. I just fear that at this stage, it's not something up my alley, but I'd gladly help with what I can. Was there source code available for the planstudio? I remember Cervator mentioning it but never saw any link to it.
And I need to get rid of this pounding headache I have
The plantstudio really is a nice tool, like Cervator suggested before, it would be a nice project to incorporate it into Terasology, letting people decide what plants to use etc. I just fear that at this stage, it's not something up my alley, but I'd gladly help with what I can. Was there source code available for the planstudio? I remember Cervator mentioning it but never saw any link to it.
And I need to get rid of this pounding headache I have
https://github.com/pdfernhout/PlantStudio/
Hubby ported parts of PS to several languages (he enjoys that sort of thing) and had it drawing plants in Java without a GUI. From the github page: "One of the most funny/ironic things anyone ever sent us was a link to a "How To" they wrote with the title "Quake goes Floral" about using PlantStudio to add some vegetation to Quake. Somehow, that seemed really hopeful."
So the idea of PS in TS someday seems hopeful as well.
Sending virtual aspirin
Hubby ported parts of PS to several languages (he enjoys that sort of thing) and had it drawing plants in Java without a GUI. From the github page: "One of the most funny/ironic things anyone ever sent us was a link to a "How To" they wrote with the title "Quake goes Floral" about using PlantStudio to add some vegetation to Quake. Somehow, that seemed really hopeful."
So the idea of PS in TS someday seems hopeful as well.
Sending virtual aspirin