text:
PubSub use of connection pool

We use go-redis in a production application for our notification protocol between microservices. Initially, we ran into an issue when using more than (I think) 8 pub/sub clients with the same redis client. After some investigating we realized that pub/sub wasn't returning the connections to the connection pool. There are two workarounds: use a single pub/sub for all subscriptions and route the messages to the correct recipients on our own, or increase the maximum number of connections of the pool.
I have just spent some time going through the code of v5 and it does look to me that the pub/sub is now correctly working with the connection pool? Or am I mistaken and we will still need to allocate one connection per pub/sub, permanently?
One a side note, it would be really nice if you could add comments to your code. I, for instance, would certainly have contributed to the project already if it was easier to find my way around the functions. Not even all the public functions are properly commented, which is a real shame. In my opinion, you should even have a lot more than that.

It definitely works - https://github.com/go-redis/redis/blob/v5/pool_test.go#L80-L91. But connection is not returned to the pool until you close subscription with pubsub.Close.

Or am I mistaken and we will still need to allocate one connection per pub/sub, permanently?

Every PubSub allocates one connection. So if you have multiple subscriptions you should keep that in mind.

In my opinion, you should even have a lot more than that.

Agreed. Not that comments will write themselves ;)

Correct me if I'm wrong, but I don't think it really works that way. From what I can see, closing the pubsub does nothing but closing the underlying base client. This includes closing the connection pool and will make all other pubsubs derived from the same client fail as well, at least as far as I can tell?
Another comment would be that it does not make sense to me why you stopped pubSub() to be exposed publicly. When you initialize an application, you might not know any channels you want to subscribe to yet. Now, you have to create some ugly wrapping code to make sure you initialize the pubsub when you get the first channel.
I don't mean to be rash, but I don't think the pubsub API is well designed in terms of making use of Go mechanics, either. Blocking functions are really ugly in Go. What about returning a channel for each subscription/pattern (or batch of subscriptions/patterns)? I think it would allow more elegant code for pubsubs.
Finally, what is the reason behind creating and using one connection for each pubsub? Personally, I would think the pubsub either needs better support to route the messages of different channels to different consumers, or the pubsub should be an abstraction, with the underlying implementation sharing a connection / connection pool. Right now, it's somehow in-between, which doesn't seem to make too much sense to me.
Looking forward to hear your comments.

at least as far as I can tell?

baseClient has it's own pool of 1 connection used for the PubSub.

Now, you have to create some ugly wrapping code to make sure you initialize the pubsub when you get the first channel.

Probably, but I don't think it is that bad. E.g. you can do
pubsub, err := client.Subscribe("some_dummy_channel")
pubsub.Subscribe("real_channel")

Probably client.Subscribe() should be changed to not require any channels. Overall I don't see a big problem here.

What about returning a channel for each subscription/pattern (or batch of subscriptions/patterns)?

i was thinking about returning one channel for all subscriptions. Anyway both can be done in user space.

needs better support to route the messages of different channels to different consumers, or the pubsub should be an abstraction

You can build this in user space on top of PubSub and share it with everyone. Current PubSub is a minimal set of API that provides you access to Redis channels without any overhead for routing/channels etc. I think that is right foundation.

The dummy channel idea is not clean at all, though.
It would be nice to have subscribe just work without channel, I tried that and I think it panicked.
If you do this in user space, you will have trouble cleanly shutting down because of the blocking calls. So you actually have to use the low level function that is recommended against with timeout. By the way, did you consider implementing things like timeouts with contexts yet? That could work really nice with pubsub as well imo.
If you think having a minimal implementation is the way to go (and I actually happen to agree), then I still believe you can't have it use one connection per subscription.
Anyway, thanks a lot for your feedback, it's appreciated.

authors: awishformore vmihailenco


text:
exit from waitUpdates function when context is terminated

After the new changes return from the waitUpdates function was lost when the passed context was terminated.

Thanks)

source: gharchive/pull-request

authors: negasus sattellite

repo: go-telegram/bot

license: MIT

license_type: permissive

license_source: github-api


text:
fix(ci): Fix silent failures in GHA reviewdog workflow

It was installing 1.18 which can panic or have a variety of silent failures.
See: https://github.com/reviewdog/action-golangci-lint/issues/249
Here is an example silent failures:

1.18 was installed: https://github.com/go-vela/worker/runs/6098658651?check_suite_focus=true#step:4:18
failed: https://github.com/go-vela/worker/runs/6098658651?check_suite_focus=true#step:4:84

  /__w/_temp/reviewdog-F3Z0zl/golangci-lint-1.45.2-linux-amd64/golangci-lint run --out-format line-number --config=.golangci.yml
  level=error msg="Timeout exceeded: try increasing it by passing --timeout option"
  /__w/_temp/reviewdog-F3Z0zl/reviewdog -f=golangci-lint -name=golangci -reporter=github-pr-review -filter-mode=diff_context -fail-on-error=true -level=error

The reviewdog action always installs go, so using the container doesn't save us anything any more. So, I dropped that.
And, it was still giving me timeout errors. However, those errors do not seem to present themselves with --verbose mode. Plus, with --verbose, if it happens again, we'll have more details about what is timing out.

LGTM
Do you plan on making this change to the other repos?

https://github.com/go-vela/server
https://github.com/go-vela/cli
https://github.com/go-vela/sdk-go
https://github.com/go-vela/types

Sure, I can do that. I want to let this soak for a few days to make sure it actually fixes it across a variety of PRs, and then I can create PRs for the other repos.

Hmm. I got another timeout that didn't fail the build. It did provide more detail however:
https://github.com/go-vela/worker/runs/6138603741?check_suite_focus=true#step:3:88
  level=info msg="[config_reader] Used config file .golangci.yml"
  level=info msg="[lintersdb] Active 39 linters: [bidichk bodyclose contextcheck deadcode dupl errcheck errorlint exportloopref funlen goconst gocyclo godot gofmt goheader goimports gomoddirectives goprintffuncname gosec gosimple govet ineffassign makezero misspell nakedret nilerr noctx nolintlint revive staticcheck structcheck stylecheck tenv typecheck unconvert unparam unused varcheck whitespace wsl]"
  level=info msg="Memory: 602 samples, avg is 44.0MB, max is 44.0MB"
  level=info msg="Execution took 1m0.0024772s"
  level=info msg="[loader] Go packages loading at mode 575 (name|compiled_files|deps|exports_file|files|imports|types_sizes) took 59.998065224s"
  level=error msg="Running error: context loading failed: failed to load packages: timed out to load packages: context deadline exceeded"
  level=error msg="Timeout exceeded: try increasing it by passing --timeout option"

for comparison, here's a success
https://github.com/go-vela/worker/runs/6138156777?check_suite_focus=true#step:3:99
level=info msg="[config_reader] Used config file .golangci.yml"
  level=info msg="[lintersdb] Active 39 linters: [bidichk bodyclose contextcheck deadcode dupl errcheck errorlint exportloopref funlen goconst gocyclo godot gofmt goheader goimports gomoddirectives goprintffuncname gosec gosimple govet ineffassign makezero misspell nakedret nilerr noctx nolintlint revive staticcheck structcheck stylecheck tenv typecheck unconvert unparam unused varcheck whitespace wsl]"
  level=info msg="[loader] Go packages loading at mode 575 (compiled_files|deps|exports_file|name|files|imports|types_sizes) took 2.958085413s"
  level=info msg="[runner/filename_unadjuster] Pre-built 0 adjustments in 25.154162ms"
  level=info msg="[linters context/goanalysis] analyzers took 16.40744639s with top 10 stages: goheader: 1.723201758s, the_only_name: 1.496035296s, buildir: 1.317900872s, unconvert: 932.734843ms, dupl: 801.118034ms, goimports: 691.825862ms, gosec: 683.622952ms, buildssa: 641.508346ms, gofmt: 590.7755[89](https://github.com/go-vela/worker/runs/6138156777?check_suite_focus=true#step:3:89)ms, directives: 443.251764ms"
  level=info msg="[runner] Issues before processing: 423, after processing: 0"
  level=info msg="[runner] Processors filtering stat (out/in): nolint: 0/158, autogenerated_exclude: 341/423, exclude-rules: 158/341, filename_unadjuster: 423/423, path_prettifier: 423/423, skip_files: 423/423, cgo: 423/423, exclude: 341/341, skip_dirs: 423/423, identifier_marker: 341/341"
  level=info msg="[runner] processing took 36.300[91](https://github.com/go-vela/worker/runs/6138156777?check_suite_focus=true#step:3:91)2ms with stages: nolint: 13.675368ms, exclude-rules: 10.98[93](https://github.com/go-vela/worker/runs/6138156777?check_suite_focus=true#step:3:93)16ms, identifier_marker: 7.712851ms, autogenerated_exclude: 1.863937ms, path_prettifier: 1.604932ms, skip_dirs: 368.607µs, cgo: 51.201µs, filename_unadjuster: 29.4µs, max_same_issues: 1.2µs, uniq_by_line: 600ns, exclude: 600ns, max_from_linter: 500ns, path_shortener: 400ns, diff: 400ns, max_per_file_from_linter: 300ns, severity-rules: 300ns, skip_files: 300ns, source_code: 300ns, path_prefixer: 200ns, sort_results: 200ns"
  level=info msg="[runner] linters took 2.987110063s with stages: goanalysis_metalinter: 2.[95](https://github.com/go-vela/worker/runs/6138156777?check_suite_focus=true#step:3:95)0683649s"
  level=info msg="File cache stats: 89 entries of total size 383.1KiB"
  level=info msg="Memory: 61 samples, avg is 131.9MB, max is 340.0MB"
  level=info msg="Execution took 5.[97](https://github.com/go-vela/worker/runs/6138156777?check_suite_focus=true#step:3:97)8173183s"

So, adding a timeout doesn't make sense (59 seconds vs 6 seconds is very different!), but I'm not sure what is failing.
Looks like we at least need something that checks for that timeout message to fail the build so we can retry or rerun or something.

repo: go-vela/worker


text:
Comments after def causes panic

class Foo
  def my_method # the comment causes panic
    49
  end
end

class Foo # the comment is safe
  def my_method
    49 # the comment is safe
  end # the comment is safe
end #the comment is safe

Fixed, see https://github.com/goby-lang/goby/compare/01eec7ba1681...be4954caf9a4

Confirmed this bug has been fixed on the current master branch.
Thank you very much!

source: gharchive/issue

repo: goby-lang/goby

license: mit

license_source: bigquery


text:
[Feature] Run in DBT Cloud

Is this your first time opening an issue?

[X] I have read the expectations for open source contributors

Describe the Feature
Lots of my colleagues uses the DBT Cloud IDE. It lowers the entry barrier for anyone not experience with IDEs, git, etc. With that in mind, I would like them to also have the possibility to write unit tests and run the tests in that environment.
Describe alternatives you've considered
Running tests in CI pipeline, but this creates a very slow feedback loop.
Who will this benefit?
Any DBT developer using DBT Cloud IDE
Are you interested in contributing this feature?
Yes
Anything else?
I have now clue if this is even remotely possible. Does that DBT cloud runtime include Pytest? Is it possible to create a DBT package which pulls in additional packages from pypi?

Hi @calleo, sorry that I missed your issue! I changed my notification settings so that this won't happen again.
I am afraid that we can not run this package in the dbt cloud. The dbt cloud blocks you from running anything other than dbt. This is on purpose, I guess they want to avoid misuse of the dbt cloud and for security reasons.

authors: JCZuurmond calleo

repo: godatadriven/pytest-dbt-core


text:
Allow omitting 'owner' in general

This is something I have been wondering about for a while, and since it was also mentioned in #848, but only in the context of construction, I wanted to open a more general discussion.

It's a common complaint that the signature of the mandatory new is too verbose, the owner argument being seldom used.

Being forced to consume an owner argument is often awkward for methods in general. I often have classes that I want to use from both GDScript and Rust side. These classes may have simple functions, like e.g. a unary start() or stop() (think of for instance an audio sequencer). For many of such functions it is totally unnecessary to consumer the owning node in the method. As long as the native class is called only from GScript this isn't much of an issue. But when using this class from Rust as well, the method signature feels wrong: Calling start(some_node) and stop(some_node) requires passing around unnecessary data, and in some contexts the owning node is simply not available, and there is no good way to call these methods at all. Then I started to implement methods in pairs, one with the owner exported to GDScript and one without the owner for usage from within Rust, where the first delegates to the latter. This is also awkward, because of the boilerplate, and because of using two function names: My functions in Rust are now for instance often called start_impl() or stop_impl(). (I just noticed that with the export rename feature, I might actually by able to call the exported functions something like start_exported(), rename it towards GDScript to "start", and call the underlying implementation start() -- in any case, quite some extra work.) Therefore, it would be great if consuming the owning node would be optional in general.
I'm not very familiar with Rust macros, but in Nim it would be quite straightforward to actually figure out whether an implemented method actually wants to consume an owner argument, and generate the wrapper call accordingly. The rule would be something like: Given the AST of the method, if the first argument after self has the appropriate type to consume the owner, the owner will be passed in as second argument. Otherwise the owner is discard in the wrapper. This would allow using an owner argument only when actually necessary. Is something like that not possible in Rust?

I agree on this, the owner is often unnecessary, and it needing to be part of the signature has mostly technical reasons. We need to investigate what would be an ergonomic way to avoid it -- maybe even default to "no-owner" and only add it on demand.
Apart from that, I think "owner" is an unfortunate name -- "base" is better. After all, owner already has a different meaning in the scene tree, and what we are really talking about is the (inherited) base class with a built-in Godot type.

But when using this class from Rust as well, the method signature feels wrong: Calling start(some_node) and stop(some_node) requires passing around unnecessary data, and in some contexts the owning node is simply not available, and there is no good way to call these methods at all.

The way how exported methods are currently implemented, is that they are not really intended to be called from Rust. Primarily, they serve as an interface to GDScript code. But I see that the possibility of calling them within Rust makes it appealing.

The rule would be something like: Given the AST of the method, if the first argument after self has the appropriate type to consume the owner, the owner will be passed in as second argument. Otherwise the owner is discard in the wrapper. This would allow using an owner argument only when actually necessary. Is something like that not possible in Rust?

A lot of things are possible with Rust macros, but it's also a question of "how much magic do we want in our APIs".
For example,
#[export]
fn collides_with(self, owner: &Node, other: &Node) -> bool { ... }

Pretty straightforward to call from GDScript:
if a.collides_with(b):
   do_something()

Now, we apply magic to omit the owner:
#[export]
fn collides_with(self, other: &Node) -> bool { ... }

How do we know that other is not the owner? Having different semantics based on parameter name opens doors for all kinds of havoc, and such surprises can be very user-hostile. Those things don't happen because you accidentally write "other" when you mean "owner", but during large-scale refactorings, and can be absolute nightmares to debug. A statically typed language focused on safety should try to minimize such hazards.
But I'm optimistic there are ways to make it explicit without being overly verbose, especially if we find "the right defaults" (e.g. most methods do or do not need an owner). Something along the lines of:
#[export(with_base)]
fn collides_with(self, base: &Node, other: &Node) -> bool { ... }

#[export]
fn collides_with(self, other: &Node) -> bool { ... }

But I'm optimistic there are ways to make it explicit without being overly verbose, especially if we find "the right defaults" (e.g. most methods do or do not need an owner).

I would suppose that this would largely be dependent on the architecture/style of the project. We are likely to see a lot of uses of the owner argument in script-style code, and rarely any in API-style code. It comes down to which one we want to make more convenient by default.

Something along the lines of:
#[export(with_base)]
fn collides_with(self, base: &Node, other: &Node) -> bool { ... }

#[export]
fn collides_with(self, other: &Node) -> bool { ... }

Another possible syntax might be:
#[export]
fn collides_with(self, #[base] b: &Node, other: &Node) -> bool { ... }

...where the presence (and position) of the owner/base argument is determined by an attribute. Owner-less would implicitly become the default, of course.

Another possible syntax might be:
#[export]
fn collides_with(self, #[base] b: &Node, other: &Node) -> bool { ... }

...where the presence (and position) of the owner/base argument is determined by an attribute. Owner-less would implicitly become the default, of course.

That's very nice. I haven't really encountered attributes in parameter position in Rust, but all the time in other languages (e.g. for REST clients). A small extra advantage would be that the user could choose which parameter acts as the base.

I like all the proposals a lot -- they'd all solve my use case just fine.
I also don't have a strong opinion on what should be the default. For me personally ~95% of the methods don't need a base/owner. The one method that almost always uses it is _ready though. Typically I do cache static tree reference there in the spirit of an onready var, which is why most other methods don't need tree access anymore. On the other hand, keeping the default as it is would mean no breaking change, and easier discoverability of the feature for newcomers -- opting out when desired would work perfectly fine as well.

My suggestion.
Use the base keyword, like the self keyword.
base is the argument of GodotObject and its type is TRef<InheritedType>.
For example:
#[inter] // Renamed from "export".
fn collides_with(&self, base, other: &Node) -> bool { ... }

omitted:
#[inter]
fn collides_with(&self, other: &Node) -> bool { ... }

Change the name of the attribute from "export" to "inter" because I dislike that name.
It is used in GDScript in the different sense.
(and compatibility is maintained)
I will implement this now for personal use. Will open a PR later.

@B-head We discussed this in https://github.com/godot-rust/godot-rust/pull/633, the conclusion was that it's "too much magic".
Generally, we would like to keep the syntax as natural as possible -- first, there's fewer special cases that humans have to memorize; second, it tends to confuse IDEs less. Of course there can be exceptions in case of massive readability benefits, but here I think adding the type improves readability.
#[export] naming can be discussed, but if at all, then I'd rather opt for something like #[method] (mirroring #[property]), and definitely not before v0.11. #[inter] doesn't seem to relate to any term in this domain (even assuming it extends to "interface" or similar).
Nevertheless thanks for the suggestions! Maybe a note regarding PRs: to avoid extra work on your side, feel free to first discuss such designs in a GitHub issue or on Discord 🙂

@Bromeon

We discussed this in https://github.com/godot-rust/godot-rust/pull/633, the conclusion was that it's "too much magic".

Thank you for the information.
To follow the discussion at that time, here is the link.
Reconsideration of the discussion at that time
Confusion in IDE

My only fear is that IDEs will have a harder time and it looks more alien since _ is generally not allowed.

True. It did confuse rust-analyzer when I tried it.

I used the code in #633 to try to see if works well with the current rust-analyzer.
Currently there seems to be only slight confusion.

Type inference
There is an argument that the code is not clear because the type of owner (or base) is inferred.
First, clarify what is problem with type inference.
For example:
fn foo(bar) {
    bar.do_something();
}

The type of bar is inferred. The type of bar depends on how foo is called.
Problem with this code.
The lack of any information about do_something().
And the user of this function needs to know the internal implementation to pass the proper type to bar.
Such code would easily make bugs.
With this in mind, consider the following example:
#[export]
fn foo(&self, base) {
    self.do_something(base.do_something());
}

The type of self and base is inferred. The type of self is &Self. The type of base is TRef<'_, <Self as NativeClass>::Base>.
Unlike the previous example, the type being inferred is definitive.
We can see what the two do_something() are.
And the user of this function can easily pass the proper types to self and base.
This would not make bugs by type inference.
Reply to comment

#[export] naming can be discussed, but if at all, then I'd rather opt for something like #[method] (mirroring #[property])

#[method] is my first choice.
Still, the reason I went with something else is that #[methods] already exists.
If there is no confusion with #[methods], I too would prefer #[method].

Maybe a note regarding PRs: to avoid extra work on your side, feel free to first discuss such designs in a GitHub issue or on Discord 🙂

It's okay. I have not written any code yet 🙄

Type inference is not the issue, I'm aware that it would not be ambiguous.
My argument against implicit owner parameter was this:

Generally, we would like to keep the syntax as natural as possible -- first, there's fewer special cases that humans have to memorize; second, it tends to confuse IDEs less. In other words, the method now needs the macro or its syntax is invalid. While at the moment, it's just a Rust method with attributes for exporting.

I'm not convinced that turning godot-rust into a domain-specific language (DSL) is the way to go, when it's possible to achieve the same with near-zero effort in standard Rust. Procedural macros always come at a cost (complexity, debuggability, compile time), and I see their main strength in avoiding boilerplate and repetition. Adding &Node or TRef<Node> is not something that strikes me as overly verbose or repetitive; on the contrary, it can help make code clearer.
Also, we need to keep GDExtensions in mind, where some things may work differently. E.g. one idea was to store the owner in the native class itself, not pass it in via method parameter. So I'd like to avoid that we spend a large amount of time of cosmetics now, which may soon become obsolete.

I'm not convinced that turning godot-rust into a domain-specific language (DSL) is the way to go, when it's possible to achieve the same with near-zero effort in standard Rust.

I fully support this. There are quite some ongoing discussions on how IDEs should handle compilation errors in proc macros. It is not only an rust-analyzer issue (iirc Clion sidesteps the issue via some heuristics), but I think this issue summarizes the challenges pretty well: https://github.com/rust-analyzer/rust-analyzer/issues/11014
I've only skimmed these discussions and have limited knowledge of proc macros. But my conclusion was that library authors are better off by keeping it simple. If I understand it correctly, proc macros should try to fall back to valid Rust code if possible, so that IDEs have a chance to capture the original semantics of the underlying Rust code. I think letting a failed macro expansion result in invalid Rust code is calling for trouble.
Side note: I was even wondering if it would make sense for godot-rust to make #[export] a valid stand-alone macro, so that we no longer need to have a proc macro on the full impl scope (in which the #[export] attributes aren't valid Rust code, leading to issue described in https://github.com/godot-rust/book/issues/57) -- but that is a different story and unclear if it would be feasible.

Apparently, no one (including me) needs the feature to omit a type. It can be supported as an optional syntax, but should not be included in the PR.
And I assume that the "the right defaults" is the omission of owner argument, since no one needs the omission of type.

And I assume that the "the right defaults" is the omission of owner argument, since no one needs the omission of type.

Yes, we would then have something like in chitoyuu's example:
// No owner/base parameter
#[export]
fn collides_with(self, other: &Node) -> bool { ... }

// Owner/base parameter
#[export]
fn collides_with(self, #[base] b: &Node, other: &Node) -> bool { ... }

This is also why I marked it as breaking change and we'll need to schedule it for v0.11 (I don't want last-minute features of this magnitude in v0.10, given that we should also change the terminology surrounding owner -> base).

authors: B-head Bromeon bluenote10 chitoyuu

repo: godot-rust/godot-rust


text:
Vectors: Default, missing Vector2 constants, documentation

Completes a part of the recent Vector2/Vector3 refactoring:

impl Default (zero vector) for both
associated constants for Vector2
documentation of constants

Let me know if there's other obvious things that could fit.

Documented "+infinity", no changes otherwise.
Regarding the new Vector API, there's one other issue I'm currently aware of -- a compiler warning:
warning: associated function is never used: `glam`
  --> gdnative-core\src\core_types\quat.rs:27:8
   |
27 |     fn glam(self) -> glam::Quat {
   |        ^^^^
   |
   = note: `#[warn(dead_code)]` on by default

We could suppress it now, or work on the Quat API, or leave it active as a reminder that we should complete the API at some point 🙂

We could suppress it now, or work on the Quat API, or leave it active as a reminder that we should complete the API at some point 🙂

Ideally we want 2, of course, but you don't have to work on it if you don't want to. 3 is a good idea, even though it might interfere with workflows where all warnings are denied (not the best idea imo, since that is simply opting out of Rust's stability). I think it can be left as is for now.

authors: Bromeon toasteater


text:
Benchmark Array functions

Adding benchmarks related to Array this was done as part of https://github.com/godotengine/godot/pull/93276

Tested locally, it works as expected.
However, these benchmarks run too fast (most of them take < 1 millisecond to complete), so they are bound to show high variance when running on the dedicated server every day. I suggest increasing the number of iterations so that each benchmark takes at least 50 milliseconds to complete (preferably 100-200 ms).

Made some changes to get benchmarks taking roughly 100-400 ms each. Check numbers below, I can try to get them closer to the 100-200 range if needed.

Running benchmark 1 of 4: core/array/append_array
Result: {"time":135.7}

Running benchmark 2 of 4: core/array/bsearch
Result: {"time":132.7}

Running benchmark 3 of 4: core/array/fill
Result: {"time":293.4}

Running benchmark 4 of 4: core/array/reverse
Result: {"time":413.8}

repo: godotengine/godot-benchmarks


text:
Shadow mapping ignores backfaces

Godot 2.1.3
Godot 3.0 alpha1
Windows 10 64 bits nVidia 940 M
Feedback from this thread: https://godotengine.org/qa/17123/render-back-faces-to-shadow-map?show=17346#c17346
Directional lights don't produce any shadow when used on backfaces. This is a must have for any optimized interior scene, or even some exterior scenes.
Lights currently project shadow only from front faces. To be honest, I think they should project shadows from backfaces instead, it makes more sense when you think about it (or there should at least be an option if projecting shadows from front faces is required).
Edit: in fact this should be an option per mesh or per material, like: "Shadow mode: none, front, back, two-sided"
Repro:

On a game level, in 3.0:

In the platformer demo:

Isn't this solved by 7e5890d?

I am unable to test it, everything is black or grey since I got latest:

This is not a bug, this is a feature. It saves shadow mapping from having to draw extra,
Nowadays, you can select front/back facing on lights for shadow mapping, or even if you want single/double sided on objects, so it should be enough. Closing this one!

Nowadays, you can select front/back facing on lights for shadow mapping, or even if you want single/double sided on objects, so it should be enough

Well... that's basically what I wanted, but where can I select this?
Also selecting double-sided on my level is a big no-no, I tried that and performance decreased noticeably (in adition to make the level harder to edit)

Check the light options. You can select double sided for shadows only
On Sep 4, 2017 3:44 PM, "Marc" notifications@github.com wrote:
Nowadays, you can select front/back facing on lights for shadow mapping, or
even if you want single/double sided on objects, so it should be enough
Well... that's basically what I wanted, but where can I select this?
Also selecting double-sided on my level is a big no-no, I tried that and
performance decreased noticeably (in adition to make the level harder to
edit)
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/10404#issuecomment-327014048,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2wMWapIlQj6ak76As5Hb8xB01LPiks5sfEUKgaJpZM4O60Uu
.

Is this new? I don't see it in alpha1. Also, why is there no backface mode only? Is this a particular gl limitation?

No, It's not in Alpha 1

Ok, I misunderstood your answer, it was just added and I missed it^^

authors: Zylann reduz vnen

repo: godotengine/godot


text:
Godot3 uses significantly more GPU memory

This affects both the editor and exported games. I have tested a blank project with debugging disabled to remove any confusion.
To replicate:

Make a new project with a blank 2D scene.
Export in release mode
Launch the exported game and take note of GPU memory usage

Godot 2.1.4: 45MB
Godot 3 alpha 2: 315MB (also confirmed in master)
The above result was on Linux64 with an NVIDIA GTX 1060.
Similarly on a Windows 10 machine with Intel HD4000 (~932 MB set aside for the GPU) any attempts to open a second instance of the editor will print errors to the console about lack of GPU memory, then crash the system. With godot2 I am able to open many instances.

This can also be a problem when developping multiplayer games...

How are you measuring GPU memory usage?
On Sun, Nov 12, 2017 at 11:06 AM, Marc notifications@github.com wrote:

This can also be a problem when developping multiplayer games...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/12831#issuecomment-343739716,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z26_BIIOdaoLZlzT2Q9rxdIPPPKJ3ks5s1vt1gaJpZM4QaWmH
.

On Linux with nvidia:
watch nvidia-smi
The following was after opening a blank project in the editor:
Sun Nov 12 11:33:28 2017
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.98                 Driver Version: 384.98                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 106...  Off  | 00000000:01:00.0  On |                  N/A |
| 25%   35C    P8     6W / 120W |    806MiB /  3013MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0      1114      G   /usr/libexec/Xorg                            244MiB |
|    0      2246      G   ...er/Downloads/Godot_v2.1.4-stable_x11.64    54MiB |
|    0      2268      G   ...user/Downloads/Godot_v3.0-alpha2_x11.64   505MiB |
+-----------------------------------------------------------------------------+

Didn't know about nvidia-smi, it's a nice tool. I can confirm the issue, on my system Godot 2.1.4 uses ~100 MiB or VRAM, while 3.0-master goes up to 700 MiB for a very simple project (scene with a Sprite using the Godot logo).

In my case thousands of objects and thousands of vertices and i get 541MiB (the running game is 361 MiB) from nvidia-smi, but godot reports 3.12 MB of video RAM

Godot 3 uses considerably more memory by default than 2. You can still change, for your game, settings to use less if you need to:

In any case, reduced some memory by reducing quality of some viewports that will not display 3D.

also there is this
https://devtalk.nvidia.com/default/topic/1026874/linux/huge-performance-losses-with-newer-nvidia-drivers/post/5223375/#5223375
if thats not the problem the increase in memory usage is a bit extreme

Alrighty - by going through the rendering settings and knocking down everything (it's a simple 2D game) I was able to get it down to 119MB. Still 2x-3x more than I hoped for, but it's low enough that my target minimum hardware is functional again.
Something that might improve UX: A 2D preset that automatically disables things you don't need. But I'm happy enough just to have a workaround.
Some final test results before signing off:
Godot3: 119MB
Godot2:	44MB
Urho3D:	27MB

Hopefully the GLES2 backend of Godot will use a lot less mem.
On Dec 6, 2017 10:57 PM, "organicpencil" notifications@github.com wrote:

Alrighty - by going through the rendering settings and knocking down
everything (it's a simple 2D game) I was able to get it down to 119MB.
Still 2x-3x more than I hoped for, but it's low enough that my target
minimum hardware is functional again.
Something that might improve UX: A 2D preset that automatically disables
things you don't need. But I'm happy enough just to have a workaround.
Some final test results before signing off:
Godot3: 119MB
Godot2: 44MB
Urho3D: 27MB
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/12831#issuecomment-349837323,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z254H4hUgaWAPk78xRTbqLT1l2vYZks5s90YjgaJpZM4QaWmH
.

oh I forgot, if you also turn off HDR in the quality settings, the memory usage should come down even further

This is currently very much an issue for me... the editor with a simple scene open takes about 700MB, the running game with that same scene (just 2 images at HD resolution and a ListView) takes over 700MB as well. That can't be normal, right? I'm hitting the limit of my 2GB of VRAM very quickly.

@kb173 That sounds like a bug. Can you create a new bug report with a minimal reproduction project so other users can reproduce your issue?

@clayjohn Just to make sure there's really something wrong before opening the issue: How much VRAM do your editor and running game use with a small project?

If you don't use 3D in your project, you can decrease RAM usage by setting Rendering > Quality > Intended Usage > Framebuffer Allocation to 2D in the Project Settings.

@kb173 Rather small, under 200mb for sure.

@clayjohn So, after a lot of testing with my whole driver setup, I got bumblebee working - I thought by only offloading Godot to the GPU, I'd have more spare VRAM. Now, as it turns out, when using bumblebee's optirun, Godot is suddenly using as much VRAM as it should! (The editor is at 139MB)
So to summarize, it seems like statically using the Nvidia GPU on a laptop which also has integrated graphics, instead of Nvidia's Optirun, can cause the VRAM usage to go way up.
I don't know if I should open a Godot issue for this, or rather report it to the Nvidia driver people or something? This whole thing is a mess.

That sounds like a NVidia driver bug. Probably best to figure it out on that end. I doubt that anything can be changed in Godot to alleviate that issue unfortunately :(

authors: Calinou Zylann akien-mga clayjohn djrm kb173 organicpencil reduz


text:
request-autotile editor- ability to mark squares as filled shapes/ autofill squares with a single click

Right now setting collusion,occlusion and navigation is extremely cumbersome, because you have to manually draw the shapes. It would save ALOT of time and effort if there is a quick command that simply fills the selected square with a square shape - instead of asking to manually create each single shape
99% of the time that is what we want anyway
See how rpg maker has it:

It takes one single click to mark a square as passable or non passable. We can also click and drag to set multiple squares as non passable and right click and drag- to set multiple squares as non passable.
Can we get a tool that emulates that somehow? Autoshape fill tool?

If you talking about top down game, that was totally fine. But how about sidescroller game? Some of my tiles I created is not full square, sometimes I need polygon shapes (non square). Well, the collision using concave which is currently not usable for KinematicBody2D.
Maybe fixing the snap function (I try the snap and doesn't work) will be more suitable

@damarindra  for more specific shapes, you can use the current shape tool and draw each square painstakingly manual as you  wish.
My proposal does not nullify the current tools. It merely compliments them.
Here I made a mockup:

That was more suitable in this situation.
Is your snap tool working?

@damarindra not sure about the autosnap- is it supposed to snap to pixels? If so- I dont think it works

@damarindra  do collisions made in the autotile editor work for you? They dont seem to work at all for me- not even showing in debug>visible collision shapes.

Found another bug here:
https://github.com/godotengine/godot/issues/13287

Snapping keep points inside of the tile, and also snaps to bitmask grid (the 2x2 and 3x3 invisible lines)

so a complete fill is 4 (easy) clicks instead of a single click, not sure if this is really necessary, difficult to implement, unless the right click deletes all the shapes on the tile (because there's no way to know which one of the shapes in the tile is the original one created with a fill, sure you can check points and see if they fit, but still not probably the best solution).
BTW @blurymind in the right side of the auto tiles tools there are Zoom In/Out/Reset buttons, it's much easier to edit shapes and record gifts using them. I originally wanted to add buttons to create shapes based on the bitmask (match mask and match non-mask), this tool was suposed to delete all shapes and create new ones. Not sure if will do it, for now it's easy enought to draw shapes.

@MarianoGnu thank you for the tip. I knew about the snap. It still takes too long as compared to a possible bucket tool.
Right now we can't even copy a shape from one tile and paste it into another. Would a copy and paste feature be easier to implement?
I mean if we can do it for bitmasks, why not also be able to do it for tile collision shapes?

copy-paste ALL the shapes together was also on the plans, and not so difficult to do

copy-paste ALL would help a lot !

Adding 6 buttons (copy, copy all, paste, paste as duplicate, paste all, paste all as duplicate) makes stuff confusing, there are a LOT of things that can be done, making the work as simple and with the best experience is important.

how about 3 buttons- copy all,paste all and a bucket fill tool-for filling
tiles quickly with a simple square
On Wed, Dec 6, 2017 at 6:09 PM, Mariano Javier Suligoy <
notifications@github.com> wrote:

Adding 6 buttons (copy, copy all, paste, paste as duplicate, paste all,
paste all as duplicate) makes stuff confusing, there are a LOT of things
that can be done, making the work as simple and with the best experience is
important.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/13283#issuecomment-349725939,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGMbVbGXzOJ7cfcUJPTlvhvSuRw1bvxPks5s9thAgaJpZM4QqgZ5
.

I'd like to throw in my support for a bucket-fill tool, I think that would help a lot. I think just copy+paste would be hugely helpful as well, even if you leave off all other operations.
I also have to manually click the save icon to get the colliders to update, but not the icon or bitmask. That is very confusing, to the point where I thought the colliders were simply broken. I can maybe look into fixing that this weekend sometime if I have the time.

This has been addressed in 3.1 when creating a square collision, it fills the whole tile. Should we close it?

It's still trash to use. See
https://youtu.be/RPgTlxb7Bno?t=469
Can we reopen this bug and make it like my gif mockup:
https://github.com/godotengine/godot/issues/13283#issuecomment-346958074

One click is required to fill a cell - not 3 steps

@blurymind Please open a proposal on the Godot Proposals repository.

Here is alink to the proposal
https://github.com/godotengine/godot-proposals/issues/648

authors: Calinou CyanBlob MarianoGnu blurymind damarindra xphere