Tutorial about godot_voxel HOT 31 CLOSED

I can help document and make a tutorial.

I've been playing with the module and studying VoxelGame. I currently have gotten my own project to work with blocky + collision, or smooth w/o collision. I can certainly create some documentation to show others how to use it in its current state. And with some help, I can learn about and document other features.

How would you like it? Wiki? .md file? Youtube? All of the above?

from godot_voxel.

I think a tutorial should be in markdown files. It needs to be updated when I work on the module though, I haven't made any doc yet because as you can see in recent commits, the API sometimes get breaking changes^^ (current voxelgame project is likely broken now)

The API doc can follow the same format as Godot, since I think it's now possible for a module to have XML docs like the engine.

I'd like to make a YouTube video one day to explain how the full stack of VoxelLodTerrain works currently, both to explain the solutions I had to take (rather than being a tutorial to use it) but also allow people to come up with potential better ideas.

from godot_voxel.

I also got this error when trying to build by just running the scon platform=windows command

from godot_voxel.

Sorry the module is a bit out of date since devs changed a few classes in the engine. There is an example project I made to show how to use the module, however it's not quite editor friendly so most of the stuff has to be done through scripting: https://github.com/Zylann/voxelgame
I'll make the module compile when I have time.

from godot_voxel.

The module should compile and run now. Still no tutorial, but I also need to improve the editor side of this module, as all things are scripted currently.

from godot_voxel.

API
Ok. Within Godot, one can search help for VoxelTerrain and it currently comes up with a list of properties and methods. It says, "There's no description. contribute one" which links to the godot-docs repository. For reference, Godot describes how to add the in-engine descriptions:
https://docs.godotengine.org/en/latest/development/cpp/custom_modules_in_cpp.html#writing-custom-documentation

Yes, neither voxelgame, nor my scene opens with last nights build of the latest engine and voxel. "Unexpected end of file" on the scene file. My project hardly uses any function calls though. The only call is VoxelBoxMover.get_motion, so maybe it was the engine updates that broke it.

Tutorial
However, the API aside, a tutorial will help new users get started without having to dissect voxelgame or read C++.

Should I assume you want to mirror whatever Godot does? They use MD files for readme's and reST for tutorials. Github will display either. e.g. https://github.com/godotengine/godot-docs/tree/master/tutorials/3d

To start off, I can submit a tutorials/ folder with an rst with what I've figured out. Then we can expand from there, including many questions I have not figured out yet. (like why channel 0=blocky, channel 1 = smooth, and Smooth Meshing Enabled doesn't seem to do anything...)

What is the best way to communicate with you on questions I can't figure out? Submit an Issue for every little thing, or chat on discord?

And by the way, thanks for putting in the awesome amount of work so far. I was thinking about creating my own voxel system and editor, so it's nice to see you're already most of the way there!

from godot_voxel.

hould I assume you want to mirror whatever Godot does?

Not necessarily. I suggested markdown despite Godot using reST because that's what I'm used to. I don't know what would be the advantages of reST over md.

To start off, I can submit a tutorials/ folder with an rst with what I've figured out. Then we can expand from there, including many questions I have not figured out yet.

I'm sorry not having clarified all those kinky details yet, there is a lot to be said. This is partly due to refactorings I've been doing, and left some stuff disabled by default, made non-dynamic or not functional until I fix them (some things could break in nasty ways if I just re-enabled them). And those changes are certainly not the last ones :p

(like why channel 0=blocky, channel 1 = smooth, and Smooth Meshing Enabled doesn't seem to do anything...)

This is the VoxelBuffer.ChannelId enum. Some of them are interpreted in specific ways, others are for arbitrary data. Enabling smooth meshing should actually work (not dynamically), but it only produces smooth terrain if there are SDF values inside channel 1 (ISOLEVEL (which I want to rename btw)). It can't just interpret the contents of channel 0 (TYPE) because they are for different purposes.

What is the best way to communicate with you on questions I can't figure out? Submit an Issue for every little thing, or chat on discord?

Github is fine, but Discord too for quick questions or longer discussions, where Github could sum them up. Although I'm often connected, I may not be able to discuss much during workdays.

from godot_voxel.

Here's a start on the tutorial. I'll submit a PR after I have a few pages built out.
https://github.com/tinmanjuggernaut/godot_voxel/tree/tutorial/doc

@Zylann I intend to insert enough instruction, and maybe code, in the tutorial to create a fly around camera, demonstrate collisions, produce blocky and smooth terrain, change materials, use opensimplexnoise or flat noise map, and add/remove voxels. Then I'd like to have the completed tutorial code in a scene in voxelgame for download. Voxelgame is a little unorganized, so I can clean up the items that are there, then add the tutorial code as a new scene. Sound OK? Can I assume the voxelgame is MIT licensed?

from godot_voxel.

Thank you for you efforts in putting this up :)
You are mostly right in the part about setting up a VoxelTerrain, but one thing to consider is that blocky and smooth terrain have different ways of working. It looks like they are together because they end up in the same mesh, but they aren't. i.e only blocky terrain can use VoxelLibrary at the moment, and smooth terrain is the only one supporting LOD. I still have to figure out how to expose this duality properly because configuring them right now is a bit of a mess, things in the editor are half-hardcoded.
Also, there is no Bullet collision support for any of them (just haven't done it yet), unless you want Minecraft physics, in which case VoxelBoxMover can help achieving this.

to create a fly around camera,

There should be a camera like this already in the demo project. I re-used it in several scenes.

Voxelgame is a little unorganized, so I can clean up the items that are there, then add the tutorial code as a new scene

I actually cleaned it up a bit already, before everything was in the same folder. Now it has one folder per runnable scene (I use some of them as tests which might not be as tutorial-friendly), and common assets remain under the root. If a new scene needs to be created for demo purpose, it should have its own folder and preferably not use assets from the others. If it needs to, either copy them, move them to root, or under a common folder.
I also have a bunch of changes locally I haven't committed yet, some of which are related to the mass renames I've been doing recently and the arrival of VoxelLodTerrain.

Can I assume the voxelgame is MIT licensed?

Yes it is, I need to add a license file.

from godot_voxel.

I actually cleaned it up a bit already, before everything was in the same folder. Now it has one folder per runnable scene (I use some of them as tests which might not be as tutorial-friendly)

Yes, it is already decently organized. I shouldn't have said it is messy. I'm looking to make it very accessible for new people who can become users and contributors.

If a new scene needs to be created for demo purpose, it should have its own folder and preferably not use assets from the others. If it needs to, either copy them, move them to root, or under a common folder.

Ok. Don't worry, organization is my forte.

I also have a bunch of changes locally I haven't committed yet, some of which are related to the mass renames I've been doing recently and the arrival of VoxelLodTerrain.

Great, I look forward to seeing them. I just published some PRs for mass rename and License. I'll be working in a new folder mostly.

from godot_voxel.

....only blocky terrain can use VoxelLibrary at the moment, and smooth terrain is the only one supporting LOD.

It's good for me to know, but for these early tutorial chapters, it won't matter to anyone. They'll only be concerned with getting a terrain running. Smooth may not use VoxelLibrary but it doesn't work without one. (Also btw, if you try and erase the library with the circle reset button or Clear, Godot crashes.)

I would like to learn about the different classes and features, which is why I've volunteered to document so I can learn how to use this code in my own projects.

Also, there is no Bullet collision support for any of them (just haven't done it yet), unless you want Minecraft physics, in which case VoxelBoxMover can help achieving this.

Yes, we need collision, pretty please!! I'd say it's the biggest thing keeping Voxel Tools from being usable at the moment. Everything else appears at least functional (generation, rendering, construction, destruction and now LOD). I have VoxelBoxMover collision working, but it doesn't seem to work with smooth terrain. Maybe I just don't know how to use it. I was thinking about using a simple downward raycast, but haven't tested it yet.

from godot_voxel.

Yeah I'm aware that things in the editor are not usable or crash-prone at the moment. I haven't focused on these so far because still have some things to figure out in the internals.

I have VoxelBoxMover collision working, but it doesn't seem to work with smooth terrain. Maybe I just don't know how to use it.

VoxelBoxMover is basically the only physics system Minecraft uses, so you could make a whole game with it if you use blocky terrain. However, it cannot be used with smooth terrain, this one will need actual Bullet collision, and probably on the nearest lod only. Also, using both at the same time might be problematic, but that would be for other issues.

from godot_voxel.

@Zylann I found raycast in VoxelTerrain, so now I have a basic collision detection working on smooth terrain! It makes an incredible difference being able to walk on solid ground, rather than fly through rock!

I've started to create an API overview document. I went through a lot of the code and between the comments and a lot of guesses, I came up with something. Can you please review this and comment on what is incorrect, answer my questions, and/or elaborate?

If it's easier and faster for you, we can go through it on a voice chat on discord and I'll take notes.

I just have a description of the classes and a little of what they do. It's missing the overall process of how things work.

https://github.com/tinmanjuggernaut/godot_voxel/tree/tutorial/doc

Thanks!

edit: updated link

from godot_voxel.

I found raycast in VoxelTerrain, so now I have a basic collision detection working on smooth terrain! It makes an incredible difference being able to walk on solid ground, rather than fly through rock!

Are you sure it works? The implementation for smooth case is quite lazy at the moment (I added it to quickly test SDF edition), but it's not really on point.

I'll have a look to your doc once I get back home.

from godot_voxel.

Yes! I can run over the terrain, climb hills, jump off them. On 3D noise, I can run down into the natural caves. It's awesome! I was going to make a video to show you but my computer is too slow. :( I should be getting a top of the line one in a few days though!

You're right it's basic, but it is useable. It only returns integer values, but I made it work. I was going to see about copying it over to VoxelLodTerrain. It may be rudimentary, but it's way better than nothing!

from godot_voxel.

I read your current work on api-overview:

On terminology, I would say that "smooth" isn't necessarily more precise. It is just as imprecise as blocky meshing, but it's better fit for organic shapes, while blocky is better suited for man-made hard-surface shapes.

Another term that comes a lot in my module currently is block: a voxel is a single unit of space, while a block is basically a "chunk" of terrain, usually N*N*N voxels, where N can be 16, 32 or whatever is setup (currently defaults to 16).

In nodes description:

Sets the voxel data source stream, terrain material, and other parameters from the editor

That should be rephrased more like "has properties to set the source stream, material and other parameters from the editor". Same for VoxelLodTerrain.

One important thing to understand with terrains: they use their VoxelStream and VoxelMeshers from multiple threads. Access is granted in the editor because I turned off terrain generation specifically here, but at runtime some things (like getting the stream from the terrain and asking it to generate a block) are prone to undefined behavior. This is partly why I need to change a few things there, like copying or adding locks to suspend threads while configurations get changed.

VoxelStream:

Can it be used by itself in GDScript? Which support LOD?

It's the base class for streams, but if used itself, it won't give you anything since it has an empty implementation. However, it allows you to add a script on it and implement functions yourself, like writing your own terrain generator. It doesn't have to support LOD if you don't use LOD (it is recommended to assert(lod == 0) then), but more importantly, it will be executed in a thread, so any access to the main thread must be done with care.
Derived classes can be used by themselves.

VoxelMesher:

can it be used by itself?

No, it's an abstract class. Contrary to VoxelStream, it cannot be implemented with a script.
However, derived classes can be used by themselves to polygonize arbitrary-sized chunks of voxels. One thing to be aware of: their initial use case was for terrains, so the input data must be padded by a certain amount of voxels to work (a method gives you that number, it's usually 1 or 2).

VoxelMesherBlocky:

Supports (?? LOD?, any other features worth mentioning?)

This one does not really support LOD (although LOD support in meshers is quite subtle), but it might in the future by simply scaling up the result, like some other meshers do.
It supports features similar to Minecraft such as cubes with baked ambient occlusion around edges, but also any kind of shape (although I think this API is not yet exposed or even tested).
It's also the fastest mesher.

VoxelMesherDMC:

Builds a mesh that has been smoothed using the Dual Marching Cubes algorithm.

I would rephrase "builds a smooth mesh".

Supports (?? LOD?, any other features worth mentioning?)

It does support LOD by simply scaling up the result. It also supports marching squares skirts, which is useful to visually hide cracks between blocks of different LOD.

VoxelMesherTransvoxel:

Builds a mesh that has been smoothed using the Transvoxel algorithm.

I would rephrase "builds a smooth mesh".

Supports (?? LOD?, any other features worth mentioning?)

Support for this one is on hold. I havent tested it recently, so maybe it's broken. It's better to use the DMC one at the moment (which is the default).

VoxelMap:

Can I say this caches or stores queried voxel data in a 3D grid for a given LOD ??

It can be used as cache but its use case is broader than that. It's basically where terrains store their voxels, and can be seen as the "infinite" equivalent of VoxelBuffer.

Whats the difference between voxel coordinates vs block coordinates?

As I explained earlier, blocks are chunks of voxels, which are then arranged in a sparse grid pattern to form the terrain. That grid has a much larger step than voxels, so a conversion is sometimes needed to get coordinates to reason within that grid. Block streaming happens using these coordinates rather than individual voxels.
However, it is not obtained with just a division: for example, coordinate of voxel (-15, 0, 0) would be in block (-1, 0, 0). But if you just divide -15 by 16, you get 0. To avoid this error, I exposed functions to convert.

VoxelBlock:

...and physics? Zylann Is this just a note for the future?

Yes, that's where I will put a reference to the collision shape.

VoxelIsoSurfaceTool:

Current brushes are sphere, plane, cube, heightmap(?? for custom drawn brushes?)

Heightmap is quite an odd one, but it makes sense when you make a world generator. You can generate it in 2D, and ask the tool to "rasterize" that portion of the world in a VoxelBuffer, which is what you have to fill when implementing a custom VoxelStream.

Voxel, VoxelLibrary:
These two are indeed only used by the blocky mesher, and I'm not sure yet if they will be used by others because it makes less sense for them. If it remains that way I might rename these in the future.

from godot_voxel.

Great thank you. That helps a lot!

Once this is done, this is as deep into documenting the API as I'll go, at least until its stabilized. And maybe its all that's needed even then, as Godot generates class definitions.

I have made the updates and later will add it to my tutorial PR since its still open. Here's the diff:
TokisanGames@bf12ecf#diff-7a451485ad8311fc4f0555a8fee672d1

Just a few questions:

Another term that comes a lot in my module currently is block: a voxel is a single unit of space, while a block is basically a "chunk" of terrain, usually NNN voxels, where N can be 16, 32 or whatever is setup (currently defaults to 16).

I noted in voxel_map.cpp:set_block_size_pow2 limits it to 8, 16, or 32. This is the right place, right?

As I explained earlier, blocks are chunks of voxels...That grid has a much larger step than voxels.

Why are there two grids? Did it not work just to have a single blocky grid? Does the smaller voxel grid help to specify where the interpolated points should be on cubes for the smooth meshers?

VoxelMesherBlocky ...supports features similar to Minecraft such as cubes with baked ambient occlusion around edges, but also any kind of shape (although I think this API is not yet exposed or even tested).

By "any kind of shape" are you referring to how this and all meshers can be used to represent a dragon or a car and not just landscapes?

By "api not exposed", does this suggest why Blocky does not work with OpenSimplexNoise, but DMC does?

Side note, on one of the screenshots you show a blocky terrain generated with 3D noise, so it worked at one point. Was this from the GDScript implementation?

VoxelIsoSurfaceTool:

Current brushes are sphere, plane, cube, heightmap(?? for custom drawn brushes?)

Heightmap is quite an odd one, but it makes sense when you make a world generator. You can generate it in 2D, and ask the tool to "rasterize" that portion of the world in a VoxelBuffer, which is what you have to fill when implementing a custom VoxelStream.

So is my guess right, that this basically means custom drawn brushes? e.g. drawing a triangle and painting (adding/removing terrain) with it?

But given what you say about VoxelStream, it sounds like it's not a brush, but closer to VoxelStreamImage, so I'm not sure what this does for this class.

Thanks!

from godot_voxel.

I noted in voxel_map.cpp:set_block_size_pow2 limits it to 8, 16, or 32. This is the right place, right?

It's the right place as far as VoxelMap is concerned, but it won't work for the rest of the system if you set it, because I haven't worked on that being dynamic yet. The reason is, changing block size is an extremely expensive operation because everything else is based on it. I made it so it's not a constant, but work remains to be done to allow users to choose it.

Why are there two grids? Did it not work just to have a single blocky grid? Does the smaller voxel grid help to specify where the interpolated points should be on cubes for the smooth meshers?

There are two grid coordinate systems. One addresses voxels individually, the other addresses blocks. It was initially required to allow streaming of the world, because loading voxels individually would have been very expensive. So instead I load chunks (like Minecraft), and those chunks lie in a grid having a step 16 times larger (because each block contains 16*16*16 voxels). When LOD is considered, there is even multiple block grids, but each having a scale higher by powers of two.
This has nothing to do with interpolation.

By "any kind of shape" are you referring to how this and all meshers can be used to represent a dragon or a car and not just landscapes?

Not really: the blocky mesher currently allows you to represent the world as cubes, but those cubes can be something else: in Minecraft, you have cubes, but also half-cubes, quads to do grass, or more complex predefined models like stairs or fences. This mesher allows you to have these, not just cubes. It's a bit like another way to do GridMaps, except it bakes a mesh instead of GPU instancing.

By "api not exposed", does this suggest why Blocky does not work with OpenSimplexNoise, but DMC does?

That's not what I mean: I explained that the blocky mesher hasnt been tested much with shapes other than cubes (although you can see a screenshot of grass voxels in the voxelgame demo). You should be able to specify those custom voxel shapes but I don't think they are well exposed.

Side note, on one of the screenshots you show a blocky terrain generated with 3D noise, so it worked at one point. Was this from the GDScript implementation?

This was indeed from the GDScript implementation, at a time where I implemented VoxelStream with a script. It can still be done. VoxelStreamNoise doesnt support blocky channel yet, but it shouldnt be too hard to bring it back.

So is my guess right, that this basically means custom drawn brushes? e.g. drawing a triangle and painting (adding/removing terrain) with it?

Well yes and no: custom drawn brushes here would be 2D, so it would only work as heightmaps. For a true custom brush, you would need a 3D image, which Godot doesn't have. That could be done by providing an existing VoxelBuffer to paste into the other, though.

But given what you say about VoxelStream, it sounds like it's not a brush, but closer to VoxelStreamImage, so I'm not sure what this does for this class.

VoxelStreams are sources of voxels, not brushes. If one is implemented as a generator, it might use VoxelIsoSurfaceTool to produce its output. VoxelStreamImage actually implements a heightmap rasterization for both blocky and smooth, which is redundant code, so maybe one day I'll just merge that with VoxelIsoSurfaceTool::do_heightmap.

from godot_voxel.

List of available classes/functions would be nice to have. Currently can't tell what is provided, at least not a glance. Seems I would need to download repo and open up demo project. Not really something can do on phone yet.

from godot_voxel.

@menip How about something like this: https://github.com/tinmanjuggernaut/godot_voxel/tree/tutorial/doc/api

This is the gdscript API so far. I made script to dump XML from Godot, an XSL to convert it to text. Maybe I'll convert it to MD instead, but this is readable as is.

I'll look into using some tool to dump a C++ API.

from godot_voxel.

Yep it's nice start. An overview on main readme would be perfect.

from godot_voxel.

from godot_voxel.

Here is a C++ API:
https://tinmanjuggernaut.github.io/godot_voxel/html/classes.html

Just straight doxygen. Couldn't figure out breathe+sphinx+doxygen.

@Zylann Both APIs are now generated on demand with a script. The C++ API generates HTML pages that are hosted by Github Pages. It's a submodule, not a branch. It will requires a setting added to your profile and you might have to create the submodule first before I can push stuff into it. We can work together once I'm ready to push everything in another week or so.

Guide for reference: https://martinhh.github.io/2014/08/27/hosting-doxygen-as-github-page/

from godot_voxel.

GDScript API is now in MD format, no longer text. Though the text XSLT still exists in the bin folder should someone want to use it.
https://github.com/tinmanjuggernaut/godot_voxel/tree/tutorial/doc/api

There are few descriptions in voxel tools, so here's what a detailed class looks like through this XSLT:
https://github.com/tinmanjuggernaut/godot_voxel/blob/tutorial/doc/tools/bak/xslt-test.md

from godot_voxel.

@menip technically you can get the API by looking at the doc view from the Godot editor, although text (MD) doc is nice to have. Godot has no concept of namespaces (all prefixed Voxel so far) so i think the classes need to be pulled manually to generate the doc.

@tinmanjuggernaut how can we use Doxygen to generate the script API and class docs? Because the C++ functions are likely to not always match their scripting API interface, and some may have slightly different intentions (precisely because they were not exposed / are internal).
In the Godot engine repo they actually write to a file rather than adding comments in C++.
Now that I think about it, maybe an XML doc like they did could work out, because it allows parsing and generation to various formats.

from godot_voxel.

Godot has no concept of namespaces (all prefixed Voxel so far) so i think the classes need to be pulled manually to generate the doc.

My script searches for script XML files based on Voxel*.

@tinmanjuggernaut how can we use Doxygen to generate the script API and class docs?

Not sure about doxygen for the script API. It's designed for C++. Instead, I'm using Godot to generate the Script API, and doxygen for the C++ class docs.

Because the C++ functions are likely to not always match their scripting API interface, and some may > have slightly different intentions (precisely because they were not exposed / are internal).

My process does not depend on the APIs being in sync. It generates docs based on the code as it is. I have two export mechanisms currently:
Godot.exe -> VT GDScript XML -> xsltproc -> VT GDScript MD
Doxygen -> VT C++ -> HTML

In the Godot engine repo they actually write to a file rather than adding comments in C++.
Now that I think about it, maybe an XML doc like they did could work out, because it allows parsing and generation to various formats.

They hand edit the XML files in godot/doc/classes. Those get compiled into the engine for in-editor help. They can be dumped from the executable with 'godot --doctool'.

I'm currently generating Voxel Tools Gdscript API XML using whatever latest binary I've made (e.g. master). It dumps out the GDScript API it was compiled with. I have already written two processors to convert the XML to Text or MD.

RE: Your note from the PR:
The MD tutorial was OK but for the class reference I would prefer to use the same system as Godot,
because Doxygen won't work well with the script API, and XML will allow to parse it into Godot Editor > docs as well as MD files.

Godot has three document types:

1. Tutorials - written in RST.
2. GD Script API - XML generated from Godot.exe and placed in doc/classes - files are hand edited, then are compiled into the engine or get processed into RST files for the online docs.
3. C++ API - XML generated via Doxygen, then converted to RST.

Sphinx processes all the RST files into pretty html.

We have the same document types:

1. Tutorials - written in MD per your preference.
2. GD Script API - XML generated from Godot and converted to MD. No descriptions added at this point.
3. C++ API - HTML generated via Doxygen using its basic, ugly templates.

To move Godot's format we will have to use RST files instead of MD, and I'll have to do a lot more work to create Sphinx templates for all the doc types, as well as the full integration of all three. There may be templates already done that I can steal from Godot, but when I first set up Doxygen+Breathe+Sphinx+Custom RST templates, it was a whole other level I wasn't ready to get into yet. Also you wanted MD instead of RST.

Given all of that information, where would you like to go?

Edit: I'm basically done with the first draft of the tutorials, and the APIs are already generated. It could be published soon. We need to setup a gh_pages branch on your repository so github will host the HTML files, as I did on the link above. (I don't know if I can push my gh_pages branch to you for the initial setup). This is level 1.

Then we could look at migrating to RST + Sphinx as level 2. Most of the work I've done will carry over. The gh_pages branch will remain.

Reference:
https://docs.godotengine.org/en/3.1/development/cpp/custom_modules_in_cpp.html#writing-custom-documentation
https://docs.godotengine.org/en/latest/community/contributing/updating_the_class_reference.html
https://github.com/godotengine/godot-docs

from godot_voxel.

Godot uses Doxygen to generate C++ API? Where did you see that?

Tutorials - written in MD per your preference.
GD Script API - XML generated from Godot and converted to MD. No descriptions added at this point.
C++ API - HTML generated via Doxygen using its basic, ugly templates.

That looks ok, I'm just not sure about Doxygen because it might end up duplicating a large part of the API docs because it would be the same as the script API.

from godot_voxel.

Godot uses Doxygen to generate C++ API? Where did you see that?

https://github.com/godotengine/godot/blob/master/doc/Doxyfile
https://github.com/godotengine/godot/blob/master/doc/Makefile

Tutorials - written in MD per your preference.
GD Script API - XML generated from Godot and converted to MD. No descriptions added at this point.
C++ API - HTML generated via Doxygen using its basic, ugly templates.

That looks ok, I'm just not sure about Doxygen because it might end up duplicating a large part of the API docs because it would be the same as the script API.

I think they serve two purposes. Those who want to write gdscript need one. Those who want to understand the C++ to extend/fix/develop it can use the complete C++ API, since there's basically no other developer docs. One day I'd like to implement other meshing algorithms, including a compute shader once Godot supports it. But so far, I've been trying to wrap my head around the module for weeks with very little understanding. I'm still stuck on the LOD raycast. So I'm going to have to go over the code bit by bit. Both sets of docs are important for different devs, no matter if they're duplicate. The gdscript dev isn't going to look at the C++ API anyway. And both are generated, so it's no extra work.

from godot_voxel.

both are generated, so it's no extra work.

There is extra work in the description of exposed methods, because the script API doesn't exactly map the C++ API and has to be written by hand in XML (even though functions fulfill same purposes, there are bindings etc). As for Godot's Doxygen, it's quite empty... maybe a contributor wanted a Doxyfile but it looks like nobody ever wrote doc comments in the source.

from godot_voxel.

Ok, well what would you like to do? VT doxygen c++ is also thin, and maybe doesn't provide much value over reading the source in a good IDE.

Do you want to cut out the c++ api and just go with the tutorial and script api all in MD?

Or those plus doxygen and a gh-pages setup to host them?

from godot_voxel.

I think script API + tutorial is a good start, and understanding that one should already give good info to understand the C++ part.

from godot_voxel.