Comments (5)
There's no question that things need to be improved, this is very much still a work in progress and has mostly just been hashing out the basic functionality of things.
I haven't had a chance to properly look over the changes you published, or test them out, but overall I generally agree with everything you are saying.
Hardcoded node paths in scripts which define rigid scene structures and have no configuration warning when not properly configured
Agree with this, and from what I've seen of the code, the changes look good as well.
No in-editor preview which would be very useful for adjusting parameters
Agree this is a pain, I recall there being a reason I didn't bother trying to make this work, but I can't remember what that reason was. If Terrain3D works as well as suggested in the other issue, I'd much rather ditch the QuadTree3D and take advantage of that. I was already looking at integrating with that plugin for shoreline interactions and such.
MotorVessel3D can only be controlled by the keyboard
MotorVessel3D overall is a very crude implementation, and was mostly only meant as just enough to be able to scoot around on the ocean I made :P.
In a final complete implementation, there definitely needs to be support for multiple propellers, and they may be in many different positions or orientations (bow thrusters for example), propellers could pivot for steering eliminating the need for rudders (or complement them), and propellers could either be fixed pitch or variable pitch.
It's probably not ideal to extend WorldEnvironment into OceanEnvironment for a couple reasons
I'm not super fond of the implementation of OceanEnvironment overall, open to alternatives.
As-is, properties in several nodes need to be modified to tweak ocean appearance
There are a lot of places that need to be touched to change the ocean. I haven't been worried too much about that so far as things are still being added and rearranged (when I have time), so I haven't spent too much time consolidating where to configure things.
would definitely prefer to contribute here than maintain a fork
I would be happy to have any contributions and pull requests you are willing to make.
from godot4-oceanfft.
Agree with this, and from what I've seen of the code, the changes look good as well.
Great! While I'm trying to keep each commit clean, definitely view my fork more as me tinkering with ideas, then once we decide on specific plans I'll make clean PRs here. Happy to do that with the buoyancy change now if you'd like?
(Re: In-Editor Preview) Agree this is a pain, I recall there being a reason I didn't bother trying to make this work, but I can't remember what that reason was. If Terrain3D works as well as suggested in the other issue, I'd much rather ditch the QuadTree3D and take advantage of that. I was already looking at integrating with that plugin for shoreline interactions and such.
I think it makes a lot of sense to integrate with Terrain3D if the user has installed it but I think it's preferable to not require it so I think this plugin should ship its own LOD solution as well, maybe preferring Terrain3D's solution if available.
MotorVessel3D overall is a very crude implementation, and was mostly only meant as just enough to be able to scoot around on the ocean I made :P.
In a final complete implementation, there definitely needs to be support for multiple propellers, and they may be in many different positions or orientations (bow thrusters for example), propellers could pivot for steering eliminating the need for rudders (or complement them), and propellers could either be fixed pitch or variable pitch.
Cool. Yeah, no worries - I was just a little unsure of your intent since it's reasonable to consider motor vessels out-of-scope and it seemed more like an example implementation. That said, IMO providing a solution is preferable.
It might make sense to do something like the existing BuoyancyBody3D
/BuoyancyProbe3D
relationship, eg MotorVesselPropeller3D
/MotorVesselRudder3D
, where then MotorVessel3D
provides steering, with each propeller/rudder having constraints defined on that object. That seems flexible/powerful to me, but solving for the steering properly might get complicated. What do you think?
It's probably not ideal to extend WorldEnvironment into OceanEnvironment for a couple reasons
I'm not super fond of the implementation of OceanEnvironment overall, open to alternatives.
Yeah I didn't suggest a better solution because I don't have one yet... I think a replacement just needs access to the camera and its environment to function and from there it's mostly a question of exposing that in a way that makes sense.
As-is, properties in several nodes need to be modified to tweak ocean appearance
There are a lot of places that need to be touched to change the ocean. I haven't been worried too much about that so far as things are still being added and rearranged (when I have time), so I haven't spent too much time consolidating where to configure things.
Yeah that makes sense. It's possible to still have that development flexibility and expose a node to the end user that does nothing but have all the settings that should be exposed centralized and sets everything else up properly using internal children. That also minimizes what a user might have to do when updating the plugin.
Going work on getting a preview working in the editor now. I'm pretty useless as far as shaders go but if you have any further thoughts on the user interface side of things that I haven't brought up let me know, I'm happy to work on implementing that side of things.
from godot4-oceanfft.
Agree with this, and from what I've seen of the code, the changes look good as well.
Great! While I'm trying to keep each commit clean, definitely view my fork more as me tinkering with ideas, then once we decide on specific plans I'll make clean PRs here. Happy to do that with the buoyancy change now if you'd like?
Sounds good! And yes you can do up the buoyancy change at your convenience.
I think it makes a lot of sense to integrate with Terrain3D if the user has installed it but I think it's preferable to not require it so I think this plugin should ship its own LOD solution as well, maybe preferring Terrain3D's solution if available.
That would be the reasonable path to go.
It might make sense to do something like the existing BuoyancyBody3D/BuoyancyProbe3D relationship, eg MotorVesselPropeller3D/MotorVesselRudder3D, where then MotorVessel3D provides steering, with each propeller/rudder having constraints defined on that object. That seems flexible/powerful to me, but solving for the steering properly might get complicated. What do you think?
If you're familiar with the game Stormworks, that is a good example of what I would think. Building each of the components with their basic function, and the placement and control of those components (including compound steering if its desired) is up to the user to define.
Having the steering be automatically calculated for a simple WASD input may be desired for simple arcade style games, but if someone is trying to build more of a ship simulator type game, then the player would expect to have much finer control over each of the propellers/rudders individually.
It's possible to still have that development flexibility and expose a node to the end user that does nothing but have all the settings that should be exposed centralized and sets everything else up properly using internal children. That also minimizes what a user might have to do when updating the plugin.
That's definitely something worth working towards.
from godot4-oceanfft.
Was not familiar with Stormworks, very cool. I've done a lot of work towards in-editor previewing and put up a somewhat rough draft PR for feedback that implements it as well as adding an OceanSurface3D node which has subclasses to render to different meshes, as part of work towards eventually supporting Terrain3D. I've done this work along the lines of thinking what would have been useful for me in using this plugin before I dug into the code and understood more of it.
I've decided I agree with you about MotorVessel3D - that seems consistent with Godot's own CharacterController3D and Vehicle3D classes and I'm all for keeping consistency with the example Godot itself has set when possible. I think there's still a question about what behaviors MotorVessel3D should support in order to be a class that an end-user can extend into something functional relatively easily. Maybe it shouldn't do much more than provide buoyancy (as it does) and register propellers/rudders for a subclass to control the behavior of.
from godot4-oceanfft.
Are there any plans to have motorVessel3D have other methods of propulsion than propellers that have to be underwater?
I was thinking the movement seemed unrealistic for something like a sailing ship since the ship could still be caught in the wind even when it's out of the water. This could maybe just be something the user would toggle on or off in the export variables.
from godot4-oceanfft.
Related Issues (13)
- wave direction error HOT 4
- Heavy buoyancy jitter HOT 7
- The speed of the MotorRectangle is very small HOT 2
- question: Generation of water surface only at height y = 0? HOT 1
- Planetary curve HOT 2
- Make wave generation parameters available to other shaders HOT 1
- Underwater particles clump up into stringy lines near the surface of the water
- Update to work with double precision build of Godot
- Window hangs when closed via the windows close button; the stop button in the editor works immediately HOT 1
- Ocean only renders in global +X/+Z quadrant direction, centered on camera, when using RADV Vulkan drivers on Linux HOT 4
- Key bindings does not work HOT 3
- better performance of mesh/lods HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from godot4-oceanfft.