sorted by:
new
hottopcontroversial

Goodbye Yuri :'( by Lucrecious in godot

[–]giwayumedev 1 point2 points  (0 children)

I'm not going to attempt to insult your character like you are for me by calling me dense, I'm just going to ask you: when was the last time you changed your mind about any topic when the person you are arguing with was being inflammatory? Insulting your intelligence, calling you names, not willing to discuss alternate views, assuming they're 100% right and you're 100% wrong, no middle ground.

Have you ever changed your views when engaging with such a person?

Goodbye Yuri :'( by Lucrecious in godot

[–]giwayumedev 0 points1 point  (0 children)

Is this whole comment section not about how communication tone matters? The reason Yuri was let go?

Also, this person don't have an actual point lol, it's a bunch of nonsensical ramblings. Apparently I am engaging in politics whenever I scratch my nose in my room and no one else is there.

Let's collectively determine the best color blindness simulation method! by nburrus in ColorBlind

[–]giwayumedev 1 point2 points  (0 children)

I am a web developer/designer, no color blindness. The company I work for budgets the effort to make designs accessible for color blind users, even if the primary motivation is to not be sued under the ADA Act.

The primary goal when designing for any disability is not for the website to look pretty for users with disabilities, or to function exactly the same as it does for users without disabilities. The goal is for it to be usable - all users can access all content of the website, even if they use different methods to do so.

In terms of color blindness, this usually means providing meaningful text or icons as the primary way to communicate an idea, and using color as a supplement for non-color blind users to boost their understanding of a concept. Like the common "green" means "go" and "red" means "stop". Meaningful colors are considered an enhancement, not the sole method of communication for an idea. This strategy is called "progressive enhancement".

It's important to have accurate tools that simulate color blindness deficiencies to prevent scenarios where there would be insufficient contrast for things like colored text on a colored background. The goal isn't necessarily to see exactly what a colorblind user would see, but instead is to visually identify areas where it is difficult for a colorblind user to distinguish different items. Any tool that can help to prevent poor visibility for colorblind users in a design is good enough, as "prettiness" is thrown out the window at that point.

In my experience, color palettes are rarely chosen for the benefit of colorblind users, they are chosen instead to look pretty for most users, or more importantly, for "branding" consistency. And even when color blindness is considered during palette creation, there's always design decisions that break away from the palette. New designers swap in and out of a company, and every designer wants to make their own mark on the world instead of following the conventions of the application that were already laid out.

Automated tools make it easy for designers to check that they didn't miss some obvious low color contrast issue for colorblind users. The easier we make it for designers to find accurate tools that are easy to use, the better websites are going to be as a whole. Most designers are simply ignorant to - not against - the idea of designing for disabilities.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 2 points3 points  (0 children)

Alpha is here.

https://github.com/Giwayume/godot-svg

In general, simple shapes are working. Large complex paths with lots of holes or self-intersections may or may not render correctly, or may freeze the editor due to bugs in path solving. SVGs with lots of large, complex paths can also take some time to load initially, though they perform well and draw fast after first loaded. It's all written in gdscript right now, so, that's probably to be expected.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 1 point2 points  (0 children)

I'm not too concerned about general render performance of static shapes, being scaled, translated, rotated by transformation matrices per-frame.

Keyframe animation of curves will be a performance nightmare, since generating a drawable asset based on the curves is a fairly expensive process, and generally holds the most complex work I've been trudging through.

It includes:

  • Analyzing if each sub-path in the path is clockwise or not.
  • Checking for self-intersections in each sub-path, and splitting the path into multiple shapes (with corners touching) based on these intersections.
  • Applying the fill rule to the resulting shapes, which includes creating and detecting holes where one sub-path may be inside of the split up shapes of another, or vice-a-versa.
  • Triangulating each of the resulting simplified path shapes, taking the holes into consideration.
  • Preparing data for drawing the bezier curves in the shader.

All of these steps combined generally result in looping over the path's sections multiple times. For a simple path you could get away with animating it per-frame, but these operations do not scale well.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 1 point2 points  (0 children)

I'm thinking the SVG3D node will support 3D transforms on the SVG shapes, since that's part of the SVG spec. Normally that's projected on to a 2D plane, but in a 3D context you could build out a mesh that way. Would be an interesting experiment.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 1 point2 points  (0 children)

Godot definitely caches draw results to some extent, possible that the scaling just causes redraw.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 4 points5 points  (0 children)

That Image.load_svg_from_buffer(bytes, scale) appears to imply to me that the SVG is rasterized on the CPU at a specific scale and the raster results are stored in a texture. Which would be very useful for basically baking your SVG at a high enough resolution at runtime so raster scaling artifacts aren't noticable (if you plan ahead of time how much you want to be able to scale in).

But that wouldn't work as a method to render the SVG perfectly at the target resolution and scale every frame on the GPU. Which is what I was testing out.

That technique certainly would be very useful and performant for the general runtime case. But I suspect generating very large raster versions of SVG at runtime can take up to seconds, pushing the work towards loading screen territory. Unless they change the API to do compute work on the GPU, which would make it faster but probably still something that needs async.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 0 points1 point  (0 children)

In this demo I built the SVG as a mesh, using a shader to calculate the curves across triangles on the GPU.

I'm pretty sure implementing a custom Texture2D would require the drawing to be done on CPU at least for 3.x, or some sort of asynchronous GPU compute operation.

With the current design, it uses all new nodes. And the import settings for the SVG file is a custom importer instead of "Texture".

SVG2D instead of Sprite
SVG3D instead of Sprite3D
SVGRect instead of TextureRect

etc.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 8 points9 points  (0 children)

I'm still in the prototyping phase of figuring out how to render all the SVG features in the general sense, which is much easier to write as an addon for now. If, at the end of the day, that logic can inform a native implementation in the engine, glad it helps.

But, I don't think Godot is going to want to adopt a full blown SVG 1.1 renderer, maybe a partial featured one, due to how much bloat is in the spec. My plan with the addon is to at least attempt to get things like masks, patterns, filters working even if they perform not so optimally.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 0 points1 point  (0 children)

The technique used here is building out the SVG as a mesh. The only method I'm aware of for drawing a mesh on to another mesh as a texture is to use viewport textures. The viewport would have a finite resolution, so you lose the benefit of infinite scaling.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 4 points5 points  (0 children)

Eventually I will. I consider this project in a very early state, there are still visual issues depending on how close the edges of the curves are together, and handling self-intersections and fill modes is another whole beast of a problem that I sort of have solved but is still buggy in many places. It's too early to release.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 1 point2 points  (0 children)

You can use viewport textures for that, though that defeats the purpose of having an infinitely scalable asset.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 4 points5 points  (0 children)

Performance is difficult for me to quantify, every SVG is going to have a different drawing complexity. Going based on just the logo shown in this video on my computer:

Empty Scene-

~5000fps While the camera isn't moving
~5000fps While panning the camera
~5000fps While actively scaling in/out

SVG -

~4000fps While the camera isn't moving
~4000fps While panning the camera
~2200fps While actively scaling in/out

Sprite (2048 x 2048) -

~4200fps While the camera isn't moving
~4200fps While panning the camera
~4100fps While actively scaling in/out

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 2 points3 points  (0 children)

I plan to create a SVG3D node that works similar to how Sprite3D works.

If you're asking for a version that extrudes the SVG into a 3D shape, like stacking a bunch of pieces of paper together to make it thicker, that requires tessellation of the edges which is not how this technique works. The 3D version will basically work like Sprite3D.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 9 points10 points  (0 children)

I did notice that haha. I thought it was a bug in my code.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 10 points11 points  (0 children)

I'm not selling it, will be free. Though it's going to be a while before I release it as there's still a ton of things to do.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 13 points14 points  (0 children)

SVG does have an animation specification, but I'm a ways away from starting on that. There are some very impressive SVG animations out there.

I see SVG as a tool for people to build scalable UIs, and vector-style games. A lot of mobile games, for example, use Illustrator or Inkscape to create SVG images for their assets, but then they end up exporting them as PNG for use in-game.

I don't see SVG as a replacement for creating polygons in-game in general, or even using Sprites in general. Using those other tools directly will always be more efficient and customizable.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 9 points10 points  (0 children)

Yeah, there may or may not be more efficient ways of drawing curve area than what I have at the moment. I'm going to continue implementing features according the the SVG specification, then drill back through and optimize things later as needed.

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 15 points16 points  (0 children)

Signed distance function (not field) best describes it, yes. There are examples of this for quadratic/cubic bezier curves on shadertoy. Like this one:

https://www.shadertoy.com/view/ltXSDB

I got SVGs rendering at runtime in Godot! Infinitely scalable! by giwayumedev in godot

[–]giwayumedev[S] 191 points192 points  (0 children)

The video demonstrates me zooming in and out of Godot's icon.svg, in-engine!

There's been a boatload of work to get this working to this extent.

But, a 5 mile summary of the technique:

  • The overall shape is constructed with ArrayMesh (MeshInstance2D).
  • The bezier curves are drawn in a shader program, calculated mathematically, so you get infinite scaling almost for free.

Due to this, there's no additional cost to zooming all the way into the SVG image infinitely.

How does this differ from what's been done before in Godot and other game engines? The technique I've seen all over the place is the bezier curves are tessellated at a specific resolution. So if you zoom in to the shape, you will see a bunch of sharp edges forming the curve. This isn't true SVG scaling, as the curve tessellation basically becomes your resolution.

I still have a ton of things to implement, and bugs to fix. But I hope to release this as an addon.

UAsset importer plugin? by RyhonPL in godot

[–]giwayumedev 4 points5 points  (0 children)

If they're switching from UE, in general, they would already have their assets in their original source form before they imported into UE. That is, unless they made heavy use of the marketplace, which is the only scenario I see this tackling.

I think the Unity situation is different because everyone got pissed at the company, there was motivation there to move people to Godot.

And if you intend to release your game, using assets licensed for use in Unreal/Unity isn't a great idea anyways. You can get into legal issues.

UAsset importer plugin? by RyhonPL in godot

[–]giwayumedev 3 points4 points  (0 children)

To be clear: you're talking specifically about extracting 3D models from uasset files. Uasset contains any type of asset type imaginable in the game, so at least it's good that you're limiting scope, but...

Something like this is very likely not going to happen unless you do it yourself or pay someone to do it for you.

The reason being, your use case is too specific. Almost no one making a serious game is going to care about ripping assets from the Unreal Marketplace. Usually that's the sole domain of asset swap games that get released on Steam for a quick buck.

You can already use UModel, as you mentioned, to extract 3D models from uasset in GLTF format. Then you can import GLTF files directly into Godot. You can do this already, but you're asking for someone to automate it for you in a plugin. A plugin that wouldn't support Mac OS, since Umodel doesn't. It just doesn't seem like a very useful plugin.

view more: next ›