I got it to work now, but I dont think you have fixed the issue.
I debugged it, and while all others verts and frags are placed in my asset (eg. Common/MatDef/.....), the grass.vert and .frag are looked up in the root of the asset. Where ofc it cant be found.
If the vert and frag for Grass and GrassImpostor is placed in the root of the asset, it works. So thats my workaround, until its fixed.
Looks cool, nice work :)
Thanks for the input. I'll update the tutorial and ask people to copy the shaders and stuff into their assets until next update. Gonna add the lighting then, and find out the best way of distributing the assets.
EDIT: It's weird tho, I believed netbeans libraries used the same root as the rest of the app. I thought that was the whole idea behind it.
@EmpirePhoenix said:
Probably a good idea to not use Futures anyway, as they are somewhat deadlock provoking.
Lol, @pspeed you see what you did? xD Now theres such lore out there, people blaming their bad threading on Futures ;)
Its not about the Futures, the issues paul mentioned can happen as well when you just use synchronized and multiple threads in a bad way.
@normen said:
Lol, @pspeed you see what you did? xD Now theres such lore out there, people blaming their bad threading on Futures ;)
Its not about the Futures, the issues paul mentioned can happen as well when you just use synchronized and multiple threads in a bad way.
Heheh. Sorry.
Though Futures are somewhat more dangerous than synchronized() because you think you are safe and can have things crop up in slightly stranger ways.
But my advice is to avoid BOTH of them when possible. Use the java.util.concurrent classes in a fully asynchronous arrangement.
Any time you can't easily visualize the flow of your data you will have problems no matter what, though.
Yeah, I agree but again note that the way I use the Futures in the proposed threading for the jME3 runloop has nothing to do with blocking really. Its just a state check which would be more cumbersome to implement threadsafe otherwise, you get the Future for free. This is why I donāt think its good when people get āafraidā of them. Starting out only knowing about ātheres some queue I have to useā and just going async all the way is basically like slamming synchronized() everywhere, you know why its fixing stuff but you donāt 100% know how it happens. I think threads should be a bit more in the minds from the start, hence the more āformalā approach.
Very glad it worked. Tho tbh. I did change some other stuff as well but I canāt remember what it wasā¦ I guess its not completely safe yet.
Also this is just a temporary fix, but Iāll warn well in advance before changing the system back. I know what the problem is now, its because I did some quick-fixes right before releasing.
Working on the light now yāall. Got some issues with point lights but it should soon be fixed.
Iāll not update until i have added shadows tho, Iāll make that the goal of next update - light and shadows.
Iām going all in with the terrain stuff now. I didnāt want to at first cause a lot of features would be lost (like full grid- and pagesize control, and the timed cache for expired pages), but those things can be added later when its all in place.
Iām gonna use the terraingrid for loading, and divide the geometry into patches (much like like the terrainquads do).
Iāve extended ImageBasedHeightMap for densitymaps now. I donāt care if it calls the density values heightData and uses getHeight etc.
Currently, the visibility and fading stuff is done from within the paging engine, but that could be moved into controls instead; much like the lod controls work on terrain.
Also, I think the planting algorithm stuff can probably be plugged in much the same way its being done for terrain generation.
EDIT: I wounāt use the actual terraingrid class and terrainquads etc. of course. Just model this system after that system so its easier to make jMP plugin.
@androlo said:
EDIT: I woun't use the actual terraingrid class and terrainquads etc. of course. Just model this system after that system so its easier to make jMP plugin.
Why not? Are you completely reinventing the terrain wheel here?
Actually I like it eing independent from the terrain stuff mostly, I only have to implement Terrain ot and offer the getHeight method, and have grass on anything thats not even remotly a terrain (like house ruins).
@EmpirePhoenix said:
Actually I like it eing independent from the terrain stuff mostly, I only have to implement Terrain ot and offer the getHeight method, and have grass on anything thats not even remotly a terrain (like house ruins).
Its not about being dependent on that stuff its just that if you want heightmap-based terrain pages then it would be silly to implement that again.
@normen said:
Its not about being dependent on that stuff its just that if you want heightmap-based terrain pages then it would be silly to implement that again.
I am not using any terrain stuff, I'm just basing the grass-generation on the heightmap system (for densities) etc. It works perfectly and I would like to utilize as much terrain system code where ever its possible.
And also use the "general concepts" of it, like having lod controls (rather then controlling fading etc. from within the paging engine).
