Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Landscape shader

Author
Message
Blendman
10
Years of Service
User Offline
Joined: 17th Feb 2014
Location: Arkeos
Posted: 2nd Mar 2018 15:50
Hi
How to merge several object in one object ? Its very interesting
Thanks
AGK2 tier1 - http://www.dracaena-studio.com
janbo
16
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 2nd Mar 2018 15:56
Quote: "How to merge several object in one object"

AddObjectMeshFromMemblock( objID, memID )
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 2nd Mar 2018 17:43 Edited at: 2nd Mar 2018 17:44
Thanks for the input guys, really appreciated.

With instancing, I wasn;t meaning AppGameKit - I know that doesn no benefit. From a tutorial I saw I think you can instance an object directly in the shader which is far faster - what he did was render a single blade of grass then instance it 9 times in the shader and place them based on a math calculation. Upon reflection I think it used a geometry shader as well, which I don't think is possible in AppGameKit? It's the same tutorial library that has the occlusion culling system, which again I think may use the geometry shader - will see if I can post the link.

For my grass I imagine I am doing the same thing, using planes that are grouped together - if you check out the minecraft thread I posted a demo there that adds the cubes to a single mesh with offset vertex positions, but it's INCREDIBLY slow - running on 4k cubes takes 1 minute plus to build it, so that's not even close to a solution for most realworld scenarios. I thought that we could just write the memblock file directly, but I can;t get anywhere with that. I can handle image memblocks no problem, can't make head nor tale of the instructions in the help file for objects....not convinced it's compeltely accurate? If we could just directly write the vertices and make an object once it would be so much quicker.

However, I also found an article that says that you can alter vertex positions in the vertex shader to cause the fragment shader section to skip - which is what we need. I can reduce the draw distance of the grass in the vertex shader, and beyond a boundry discard the fragment shader, but the problem is every single fragment shader is still processed regardless - you can't discard the vertice. Had a look and method one didn't work (moving it outside the -1,1 cube), but there's another technique that I can try, will see how that goes.
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 3rd Mar 2018 03:32
So I've been playing around with the lighting and trying to get it set to work with full day/night cycles (just because....well, why not). For some reason my "sun" object can orbit no problem, but every second frame mirrors itself. So for the mean time I'm using a joystick. Also added the specular lighting with a scalable option, but really not happy with it yet, think it's not working as intended.


Jack
20
Years of Service
User Offline
Joined: 4th Oct 2004
Location: [Germany]
Posted: 9th Mar 2018 22:59 Edited at: 9th Mar 2018 23:16
Hello Santman,

you did make good progress.
I found some old work, where I try to use the image channels of a secondary texture as layer alpha maps. It is based on the Battlefield 1/ Starwars Battlefront terrain shader, an concept used in modern engines.
An alpha image with four atlas layers can handle up to 16 textures layers on the terrain.

Well the system has some bugs, as you see the mipmapping interpolation lines,
but the concept for up to 16 alpha layers has some potential.
- You can manage the problems


I've attached you some code.
This fits pretty well in your system, as you already can display textures with no mipmapping errors.
Greetings, Jack

[/url]

Attachments

Login to view attachments
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 10th Mar 2018 15:37
Hi Jack, thanks for the input.

This is just an atlas texture, you could put as many images on it as you liked to be honest, could be 15*15 textures (though the layers would slow it down a fair bit) - I worked a solution to the mip mapping lines that didn't rely on padding the textures, you could swap them out as much as you want. All you do is offset the texel look up really. This just gradients the images from 1st to last based on height, I want to look at overlaying an image that allows you to specify which texture is used, but that's more work and I think I might abandon 3D in AppGameKit, it's too slow.

Finishing of a word game right now and got a lot of actual work on - when I get the chance I'll update this thread with the mip mapping fixed and normal/specular active.
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 11th Mar 2018 04:04
OK, so I had to go looking again.....the grass was killing the game totally once everything was built into the main game and on a planet, so I figured there must be a better way to do it. There is.

Attached shows 20,000 plane objects created in AppGameKit on the left, done normally (using clone, instance etc) - when all on screen averages below 30fps with just the grass. :-(

On the right, a very early image of 20,000 plane objects as grass, ths time hitting 1000+ fps at distance, and still 450+ up close and personal.

So just for laughs, I ran it with 40,000 and it still hits 330 fps, and 80,000 hits about 130fps - taking less than 1 second to set up.

Some tweaking to do, and need to get it running with my shader again, but once that is done thick, lush grass should be totally possible. He hopes....fingers crossed! Lol.

Attachments

Login to view attachments
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 11th Mar 2018 04:44
And just for fun, here's a video of 80,000 plane objects moving independantly through the vertext shader at 160fps (animation needs improved still, but it works sorta).

george++
AGK Tool Maker
17
Years of Service
User Offline
Joined: 13th May 2007
Location: Thessaloniki, Hellas
Posted: 11th Mar 2018 05:01
All I can say: fantastic
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 11th Mar 2018 11:42
Thanks George......it's getting there. Some depth clipping going on I need to sort, but once that's fixed it should look quite cool in my planet code.

I aim to can be it to implement other things.....this easily now changes to build walls in my space shape as they are constructed from planes too...can procedurally let the player design a ship and build the entire 3d interior as a single object. Should speed things up nicely.
janbo
16
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 11th Mar 2018 13:08 Edited at: 11th Mar 2018 13:08
So is this one object with 80,000*4 vertices ? and you are moving the vertices's on a flat ground via the Vertex shader ?
Are you going to use the hight map in the vertex shader to place them on the Y coordinate accordingly ?
Well done
Blendman
10
Years of Service
User Offline
Joined: 17th Feb 2014
Location: Arkeos
Posted: 11th Mar 2018 13:15
Amazing !
Have you try it on android too ?

AGK2 tier1 - http://www.dracaena-studio.com
Rick Nasher
7
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 11th Mar 2018 13:54
Curieus to see what would look like combined with the previous terrain shots. Or is that a nogo?
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 11th Mar 2018 14:10
Janbo, that's exactly right - there's a function that you pass in a root X, Y and Z position to, then the planes are made out of pairs of triangles with the vertex positions offset.....so the exact plan is to take the ground height and set the Y position to equal that point in space. Will even automatically angle the planes diagonally when done. Using a sin/cos rotation on the Y axis also allows angling, and changing the spacing allows total control over the size of each. Shader doesn't need to do this, but it could actually. As it's also a memblock, it can be saved off as one object.....so setting up grass and then saving while levels in a single file that can be loaded with two commands is possible.

Blendman, not tried an android, but I will....but I have an S8 plus, so maybe not the best tasting device.

Rick, it's already in the landscape the first way, generating grass based on height from a water plane.....bit that was down to about 40fps with 1500 tufts (pre made groups of 15 planes), and as they were placed based on the root coords they floated and went inside the ground. These ones will have individual vertice positions set based on the getgroundheight command, so that should all vanish.

Watch this space.
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 11th Mar 2018 20:06
That's the depth issue fixed, and transparency implimented within the shader fixing the "flickers" - running 100k planes at a steady 170 fps. Now to add generation of a height map, plotting the grass on it, then add rotation and I'm good to go.
puzzler2018
User Banned
Posted: 11th Mar 2018 20:20
Congratulations my good fellow
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 11th Mar 2018 20:40
And here we go - 100k grass tufts, mving through a vertex shader, plotted across a landscape using height data to not only plot it, but also to thin the grass as the height increases smoothly. Watch to the end where you get a look underneath - actually works out as a relatively cool effect - replace the grass turfs with a texture with a dot and you'd get a point outline of the landscape with it hidden. Scanner anyone? Lol.

janbo
16
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 11th Mar 2018 21:50 Edited at: 11th Mar 2018 21:52
Does it make sense to rotate the grass to the ground normal ? (normally it growth to the sun right ?) You can calculate the normal from the differences between the neighboring vertex height.

Other question: Does the grass point in one and direction ? or do they follow the camera ? or did you made 2 planes like a cross ? can't see it... you only look from one side at the terrain
Looking forward to play with the shader.
Again well done !
puzzler2018
User Banned
Posted: 11th Mar 2018 21:53
me too lol
Blendman
10
Years of Service
User Offline
Joined: 17th Feb 2014
Location: Arkeos
Posted: 11th Mar 2018 22:00
Great !
Do you know that you could create a great fur for a character too, with your technic
AGK2 tier1 - http://www.dracaena-studio.com
puzzler2018
User Banned
Posted: 11th Mar 2018 22:13
All i like to know how to pass vertices into a shader and i can take it from there

Pleeeeese
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 11th Mar 2018 22:47
No, you mis understand. The grass isn't rotating to face the landscape or camera, they are fixed. In the first demo I used three over lapped planes at 120 degree intervals so grass is visible from any angle. At the moment all these planes face one way, so I want to set it so that every second and third rotate at 120 degrees to the first again to get the same effect. Working on the 3d space rotation now, but it's not working.

Once it's in the landscape I'll upload it again, but in fairness the shader is doing very little beyond drawing the transparency (Using setobjecttransoarency is giving ghosted edges). The work is code memblock code that builds a single mesh.

Blendman, I considered fur too actually....the only hard part would be placement of the objects I guess.
janbo
16
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 11th Mar 2018 23:20 Edited at: 11th Mar 2018 23:25
Quote: "In the first demo I used three over lapped planes at 120 degree intervals"
Okay, the "cross" method isn't far away then, maybe you consider it to save one plane per grass "tuft" <- never heard that word.
Quote: "The work is code memblock code that builds a single mesh"
But you are setting the position in the shader, not ? Or is it all saved in the mesh data
Anyway, the important part is that its one object so you don't need to switch textures etc

I don't think this method is good for fur, how would you make it work with animations ?
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 11th Mar 2018 23:39
Nope, the movement is in the vertex Shader, the position is fixed in the mesh.

It would work for fur, exactly as it does for grass. Think shadow of colluses and loads of other games. Movement is based on the texturing if data....the she's texture from 0.0 to 1.0......all the grass vertex shader does is check if the current uv for the vertex is less than 1.0, which in my case is the top of the plane. Then it knows to apply the movement.

If you rotate the plane upside down the texture uv coords rotate too - the texture would be upside down, so the bottom would move. Hence? For. But instead of a sine wave, you could apply force vectors to move the top UVs (bottom of the shape).

Originally the grass was sit in the middle, and a two stage check moved the middle less than the top.....but for grass the visible difference was so small it wasn't worth the extra calculations.

You've never heard of a tuft of grass? Really?
janbo
16
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 11th Mar 2018 23:49 Edited at: 11th Mar 2018 23:59
Quote: "It would work for fur, exactly as it does for grass"
If you say so, with animations I meant fur on animated characters, but surprise me
Quote: "You've never heard of a tuft of grass? Really?"
Haha not in English, in Germany it kinda sounds cute for a bunch of grass and the translation would be "Büschel" i guess.

I was playing with Grass too recently and thought about creating one huge mesh for it too, but you can also gain some performance if the engine can ignore a whole object because its outside of the view frustum.
So you can make one object for each tuft or make one object for all tufts, but I guess you get the best result if you balance it in between these two methods.
So split it up like the terrain does in 4, 8 or 16 parts so AppGameKit can cull it and save some time.
I saw the grass disappearing in the distance.. do you put the tufts outside the frustum so AppGameKit cull's it ?
I'm asking to many questions
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 12th Mar 2018 00:32
Ask away - I'm learning just as much back. The disappearance is done via a cal within the shader - it works out a spherical radius around the camera (the distance is controllable) and just abandons any fragments outside that. For my setup this doesn't bring much benefit but on slower devices it can add some speed. I think for more complex objects it would be good (multiplpe fragment calcs) - was going to look at a simple tree imposter system using it - make the complax 3d model, and a plane with a pic....then outside a certain distance discard fragments for the complex model, and within it discard the plane. But it comes with issue - the plane has to face the camera all the time, and without threading that means mega slow down. PLus the artifatcs from before. Wish oh wish there was a "discard vertice" inside the vertex shader. Lol.

I tried moving them outside the frustrum (setting w=2.0) but that made zero difference as AppGameKit was still rendering them.....wonder if it would work with the sigle mesh though. Either way, it created visual artifacts when only half the plane moved outside, so will work on it.

Using that distance measure though you could easily fade it in at the outside - sure that's something I heard you mention.
janbo
16
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 12th Mar 2018 01:17
You got Slack ? maybe I can help you out a little bit.
Xaby
FPSC Reloaded TGC Backer
17
Years of Service
User Offline
Joined: 17th Apr 2007
Location: Berlin
Posted: 12th Mar 2018 07:55 Edited at: 12th Mar 2018 07:56
With that, we could do some Hair, Clothes, Ribbons ... Trees with leaves? Birds with feathers

So we could combine 1.000 low Poly-objects to One single object and it would be a great performance? It would be great, to have that as a nativ command in AppGameKit somehow.

By the way: great work, fantastic. Love it.
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 12th Mar 2018 09:49 Edited at: 12th Mar 2018 09:51
Slack? Never heard of it, but happy to change that if you let me know.

Xaby, that's some grand plans. Lol. This isnt going to help any with clothes or ribbons though I don't think. You can already add objects together in AGK.....there's a command to add a memblock to an objects mesh, but it's not the quickest and from what I've seen, not hugely faster to render (Ser the GG loader)....assuming the issue is because that creates new children and each still needs to be sent separately down the render pipeline. This way, creating it from scratch in a memblock is super quick (for planes at least - this is writing 200,000 triangles, with 6 vertice points each, and 8 pieces of data.....9,600,000 bits of data) in about 0.4 seconds.

I was thinking about the Minecraft thing though - totally convinced that this would make that viable in terms of performance, and if we index what vertices relate to what block (easy enough) we could easily add and delete specific points. The issue would be identifying contacts to know what to delete, as a single object for all blocks would stop collision detection the way it traditionally worked. You'd also need a custom shader to draw faces. That's for another day though.

As is, when I'm happy with it I'll add a file which you can #include# to make use of grass planes easy and fire it up.
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 12th Mar 2018 14:14
Here's a modded version, with some spooky fog:
The code is dark and full of errors

Attachments

Login to view attachments
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 12th Mar 2018 16:20
I was wondering when that was coming.

Can't wait to see it
janbo
16
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 12th Mar 2018 23:03 Edited at: 12th Mar 2018 23:06
Quote: "Slack? Never heard of it"
AppGameKit SLACK Group
Quote: "I was thinking about the Minecraft thing though - totally convinced that this would make that viable in terms of performance"
Exactly what I was saying the whole time...
Therefore I want to create individual meshes in one object and be able to add and remove them...we already can add meshes with AddObjectMeshFromMemblock but not remove them

@Van B: Nice mod !
puzzler2018
User Banned
Posted: 12th Mar 2018 23:09 Edited at: 12th Mar 2018 23:14
If i only knew how can programme like you guys with memblocks like the back of my hand.. - like you guys..

For me is I like to know what im programming, how it works, why it works etc

so I can teach others my skills

It will come soon when ive learnt

A bit like making coffee - we need water and coffee beans together.

We all have to start from the beginning with everything....
janbo
16
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 12th Mar 2018 23:15
Quote: "It will come soon when ive learnt"
great dedication
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 13th Mar 2018 01:53
I'll have a bash at minecraft blocks again soon - with what I know now, adding and deleting meshes is actually fairly straight forward. Now the task is identifying a collision. What I'm thinking is a small area of cubes around the player, used to detect collision that is translated into world coords for creation and deletion.
puzzler2018
User Banned
Posted: 13th Mar 2018 07:11
Thanks
Rick Nasher
7
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 18th Mar 2018 08:50 Edited at: 18th Mar 2018 09:08
Would love to try and walk on that grass, any demo's?

The previous landscape demo unfortunately kills the fps too much on my aging rig, so I wonder how the grass stuff will do.

I've build a grass/plant system in the past in Blitz3D(however plagued by transparency issues due to it's DX7 nature), but never using shaders, so I'm quite curious to see how will hold up.
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 18th Mar 2018 16:31
Hi Rik,

That demo was rubbish, the code hasn't been udpated since I solved the mip-mapping...turning that one moved it from 80fps on my machine to 400+, so that's no issue. I;ve done playing witht he minecraft style engine, and in the course brushed up my memblock understanding, so now looking at the grass and foliage again.....give it a week and I hope to have something really nice to share.
Rick Nasher
7
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 18th Mar 2018 18:07
Cool. Can't wait.
puzzler2018
User Banned
Posted: 30th Mar 2018 00:51 Edited at: 30th Mar 2018 00:52
[


Keep going x
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 30th Mar 2018 18:56 Edited at: 31st Mar 2018 18:25
Ok, so been a little while, but I've totally changed things up. So now what I've gone for is using everything I've learned aboput memblocks to go with a massive open world style approach, to see how far I can push it. Here we see a (in my opinion) massive enviroment that can be easily designed with the mouse to raise and lower the land, with the shader doing all the hard work in the back ground around layers. But some new stuff here:

*ability to detect and edit the landscape, detecting where and which vertices to change
*all normals are reset to allow for a WIP but nice lighting effect
*the shader can now have the bands for the different textures manually set and controlled in realtime
*everything is meshes so it can be saved as a memblock and then loaded in as game levels/chunks at any time

I think I will extend this into a basic landscape editor that I can use to build my own levels, so next up is:
loading and saving
some better tools for editing - more refinement
better lighting by extending the vertex calculations - faster editing thanks to restricting the vertice range calculated when editing
vegetation
the ability to import models
variable texture scaling for LOD - keep the speed up in the distance for less powerful devices

What do we think so far? All comments and suggestions welcome.

fubarpk
Retired Moderator
19
Years of Service
User Offline
Joined: 11th Jan 2005
Playing: AGK is my friend
Posted: 31st Mar 2018 02:38
That looks Awesome Santman
fubar
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 31st Mar 2018 06:19
I agree with fubarpk! Very nice work.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Rick Nasher
7
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 31st Mar 2018 22:27
@Santman
Looking good.

Quote: " some better tools for editing - more refinement"

- What would be cool is a cliff tool for steep cuts and, what I've only seen once in a terrain editor(but unfortunately can't remember which ) is a bulldozer tool, to carve out roads and such, very handy.

Quote: "*everything is meshes so it can be saved as a memblock and then loaded in as game levels/chunks at any time"

- Would be nice to also have the ability to save as a heightmap.

Question: of course not usable in heightmaps, but as it is a mesh, would it be possible to carve tunnels/caves?
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 1st Apr 2018 03:16
Hi Rik.

Cliffs are easy enough to do, at the moment it has the ability to raise/lower any vertex....once done you could move that vertex back slightly to be below but behind the one above it, easy cliff face. Caves are a whole other kettle of fish though, don't know about that.

Height maps would be much easier than the way I've chosen, but with some playing it's purely the green channel that determines the height in AppGameKit, so the height map would have a maximum of 256 levels. By using a mesh I can then scale it up to whatever size I want.....the plan is to stand on the ground and in the distance see a massive mountain......and be able to walk all the over to it. But time will tell. As stands, every chunk of the world comes in at 2.5mb.....so in this form probably only really pc friendly. Smaller meshes would make it mobile friendly too though.
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 19th Apr 2018 01:37 Edited at: 19th Apr 2018 02:00
So actual life and work has kept me bust for a while, but here's a quick update on the landscape editor in action, with some scale and the grass system built in (though for reasons I can't figure right now the swaying has stopped!!).



Here we see some interesting features (I think):
*Loading and saving (load anywhere, including mobiles)
*Easy landscape scupting
*Decent draw distances
*Automatic grass/vegetation using draw zones - you draw where it goes, the builder makes it happen
*Grass height linked to map - the more transparent the alpha the smaller the grass, so it tapers in
*Normal mapping functional (much more work on lighting to come here)
*Walk mode - explore your creations
*World composed of chunks so in theory could load as you go and be virtually infinite


Here we see a simple demo of a test landscape, then we build a small mountain, and fianlly plant some grass.

Alot more tools to come. Anyone interested in this type of thing?

Next up:
*Saving grass so that it imports
*Sort seams between chunks
*Paths (drawn on the landscape
*Multiple grass/flower layers overlapping
*Better grass (going to copy Far Cry 5)
*Smoothing tool for the landscape
*Better lighting by using a larger averaging area for normals
*Importing objects
fubarpk
Retired Moderator
19
Years of Service
User Offline
Joined: 11th Jan 2005
Playing: AGK is my friend
Posted: 19th Apr 2018 02:57
Looks Awesome Santman
fubar
Rick Nasher
7
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 19th Apr 2018 07:48 Edited at: 19th Apr 2018 08:01
Very cool stuff. It looks like the textures type is related to the terrain height which is fine of course to start out with, but in nature there can be some variations to this.
Is it possible to override and add textures by choice, for instance rocky bits near the shore where there would otherwise be a sand texture for example?
Of course it's not a necessity, for one can also add rocky objects later.


Also, do you plan on multiple vegetation types?

In my above mentioned Blitz vegetation system I drew different colors on the vegetation map, different color meaning a different plant type.
e.g. grass would be bright green, corn would be yellow, bush would be dark green, berry bushes would be purple, light brown would be tree type1, dark brown tree type2, pink would be waterlelies(that would move up down with the waterlevel) etc.


Was very easy to use like that.
Green7
19
Years of Service
User Offline
Joined: 23rd Nov 2005
Location: Switzerland
Posted: 19th Apr 2018 08:19
@ rick: janbo and me got such a system up and running, i call it "plant map".
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 19th Apr 2018 09:04
Thanks guys, it's getti g there. Spent a week effectively trying to work out the terrain height using maths as I couldn't get raycasting to work......turns out I reversed up and down so it's good now. Lol.

Rik, multiple plants and such will come, but I plan to use a different system and allow multiple maps per "chunk" of terrain. So you will draw up to four maps and assign each a different vegetation type. Using this method as every grass object is part of one single mesh, so one draw call for speed. I'll mix that with tree and bush placement so you'll be able to get decent result pretty fast.

Drawing directly in it should be no issue. I did an earlier video of simple path drawing - that was super crude but when I do that properly it should lend itself to drawing directly on the map.

I also think I'll reduce the land texture and go with a detail overlay for up close.....speed is still well above 100fps, but objects and redrawing of pixels they bring will drop it, so trying not to kill the speed.

Login to post a reply

Server time is: 2024-11-23 20:41:19
Your offset time is: 2024-11-23 20:41:19