Speaking about Grassparty-BE, ive actually started the core for this package, I was wanting to get a few views on grass placement. My old system, Blitzgrass3D used several methods, none of which i think were too popular with the community.
Theres heightmap placement, standard position placement, positioning on height scale etc.. The problem is no two game engines are coded the same. While one may want to place large amounts of grass via a heightmap, another may find it does not work for them. I want to add the most standard, universal, placement option I can come up with. Which is grass=gpLoadGrass(blah blah) : positionentity grass, x, y, z.
While this is the standard call to load a grass entity into the scene, it can become quite time consuming for LARGE scale maps.
The core system sits on a huge virtual grid system, when initalizing the core you give it the lowest x/z position of your map the most x/z position of the map. The grid is then laid out in type chunks. Entitys are assigned to the chunks, sub chunks are then divided down to increase performance. Each entity utilizes a very small memory foothold so allowing utterly 70K plus grass entites is actually a reality. Its just figuring out how the community would like the grass placed.
Example of grid initalizing:
InitGrassParty(x1, z1, x2, z2)
thats it, simple huh.
Theres no real way for me to determine the boundries of a map using blitz3d commands, I wish there were.
For a grid system to flurish it must utilize grid points.
Grid points require some sorta organization throughout.
So the only real alternative is to have the user supply the lowermost x/z positions of their map and the upper most x/z positions of the map, y positions isn't factor in by the portal examiner.
Once the x/z's are given the core creates a complete virtual grid system and assigns grid points, for very large maps each grid point is broke down into sub points and assigned an entirely new grid structure. So checking things like 'did the player step on the grass?' is as simple as checking against only a handle full of grass entities instead of the 50,000 entities loaded into the system.
Blitzgrass3d used a single grid system, while it was extremely fast at 5,000 grass entities, it suffered with large amounts of entities thrown at it. The lack of grid points and sub grid points were noticeable. I tend to correct this from the get-goe by intergrating the sub-systems, one level deep, the developer can treat a loaded map as several loaded maps giving him/her near unlimited grass entity possibilites.
That's the basis of the system, but the current delima is placement. What is the best way or ways to allow placing grass onto the developers map. I have several ideas but don't want to spend days implementing them if someone else has a better idea or someone wants it done differently.
I'm open to suggestions on this, please send them in! :)
Theres heightmap placement, standard position placement, positioning on height scale etc.. The problem is no two game engines are coded the same. While one may want to place large amounts of grass via a heightmap, another may find it does not work for them. I want to add the most standard, universal, placement option I can come up with. Which is grass=gpLoadGrass(blah blah) : positionentity grass, x, y, z.
While this is the standard call to load a grass entity into the scene, it can become quite time consuming for LARGE scale maps.
The core system sits on a huge virtual grid system, when initalizing the core you give it the lowest x/z position of your map the most x/z position of the map. The grid is then laid out in type chunks. Entitys are assigned to the chunks, sub chunks are then divided down to increase performance. Each entity utilizes a very small memory foothold so allowing utterly 70K plus grass entites is actually a reality. Its just figuring out how the community would like the grass placed.
Example of grid initalizing:
InitGrassParty(x1, z1, x2, z2)
thats it, simple huh.
Theres no real way for me to determine the boundries of a map using blitz3d commands, I wish there were.
For a grid system to flurish it must utilize grid points.
Grid points require some sorta organization throughout.
So the only real alternative is to have the user supply the lowermost x/z positions of their map and the upper most x/z positions of the map, y positions isn't factor in by the portal examiner.
Once the x/z's are given the core creates a complete virtual grid system and assigns grid points, for very large maps each grid point is broke down into sub points and assigned an entirely new grid structure. So checking things like 'did the player step on the grass?' is as simple as checking against only a handle full of grass entities instead of the 50,000 entities loaded into the system.
Blitzgrass3d used a single grid system, while it was extremely fast at 5,000 grass entities, it suffered with large amounts of entities thrown at it. The lack of grid points and sub grid points were noticeable. I tend to correct this from the get-goe by intergrating the sub-systems, one level deep, the developer can treat a loaded map as several loaded maps giving him/her near unlimited grass entity possibilites.
That's the basis of the system, but the current delima is placement. What is the best way or ways to allow placing grass onto the developers map. I have several ideas but don't want to spend days implementing them if someone else has a better idea or someone wants it done differently.
I'm open to suggestions on this, please send them in! :)