The Rust Programming Language Forum forum

iced has a Shader widget which is like a 3D canvas and allows you to draw custom contents. I'm not very familiar with the wgpu api, but if you can import a raw vulkan resource as a wgpu texture, you can use that to draw the image. the widget api is a bit hard to use though. docs.rs Shader in iced::widget::shader - Rust A widget which can render custom shaders with Iced’s `wgpu` backend. if you are familiar with immediate mode gui, you can try egui . since it's immediate mode, it's very straightforward to draw custom widgets: you can simply add a paint callback for the ui content. the code for wgpu backend looks like this: fn main() -> eframe::Result { // the default option selects wgpu renderer, as long as // the feature is enabled, which is enabled by default let native_options = eframe::NativeOptions::default(); eframe::run_native("MyApp", native_options, Box::new(|cc| Ok(Box::new(MyEguiApp::new(cc))))) } impl eframe::App for MyEguiApp { fn ui(&mut self, ui: &mut egui::Ui, frame: &mut eframe::Frame) { egui::CentralPanel::default().show(ui, |ui| { let rect = ui.max_rect(); ui.painter().add(egui_wgpu::Callback::new_paint_callback( rect, MyPaintCallback::new(), )); }); } } impl egui_wgpu::CallbackTrait for MyPaintCallback { fn pain( &self, info: egui::PaintCallbackInfo, render_pass: &mut wgpu::RenderPass , resources: &egui_wgpu::CallbackResources, ) { // use the render pass to draw } } documentation for the wgpu paint callback: docs.rs CallbackTrait in egui_wgpu - Rust A callb

Thanks for the explanation! Currently I am trying to use this pattern_type! for niche optimization. If this is not currently possible I'll use the regular data type and leave this optimization for a future version of Rust.

Hi all. I'm starting on a Vulkan-compute heavy project and am using Vulkano for my work. However, I want to be able to display the results of this work in a widget inside a UI, and want to use Iced, as I enjoy using it. Iced's main backend is wgpu, which may use Vulkan under the hood depending on the platform, and I was wondering if there was a way to either share gpu memory between an iced widget and my Vulkano code, or a way to transfer an image to wgpu without going through main memory. I know I can output the compute results back to main memory and then reupload to iced, but these images may be quite large so might have a lot of overhead. Alternatively, if anyone knows of a gui crate that would handle this better, I'd be happy to try it out. Thanks.

It should show the images not being stretched out, I am unsure why this happens. This is specifically only about mode 3 main.rs (click for more details) lib.rs (click for more details)

Jookia: Fair enough, I need to provide storage for my data. But how? To store data somewhere , not on the stack, use Box . Somewhere is also known as heap : #[derive(Debug)] struct HelpMeHelper { helper: Box >, } fn help_me_new (data: &'a [u8]) -> HelpMeHelper { let helper = HelpMe { data: &data }; return HelpMeHelper { helper: Box::new(helper) }; }

vanleefxp: so is this error a result of the incompleteness of this feature? Based on reading the tracking issue for generic_pattern_types , I'd say this feature is quite early-stage and that most things are still very much unimplemented (there is not even a RFC yet). The pattern type as the return type of a function works, for example: fn foo () -> pattern_type!(u8 is 0..EDO) { unsafe { std::mem::transmute(0u8) } } whereas your snippet doesn't. This looks to me like an issue of an incomplete and yet to be specified implementation of generic_pattern_types .

The code snippet is as follows: #![feature( const_trait_impl, pattern_type_macro, pattern_types, pattern_type_range_trait, generic_const_exprs, generic_pattern_types, const_range, const_range_bounds )] #![allow(internal_features, incomplete_features)] pub struct OTone (pattern_type!(u8 is 0..EDO)); And a compile error shows up over the pattern_type! declaration: "Unconstrained generic constant". I don't understand why I can't use the declared generic constant in pattern_type! 's bounds. I think this should be totally valid. I know that currently pattern_type! is an experimental and internal feature, so is this error a result of the incompleteness of this feature?

Hi rustaceans, I'd like to share RsHtml , a template engine I developed for Rust. RsHtml is a compile-time, type-safe, lightweight, and flexible template engine for Rust. It aims to seamlessly integrate Rust code with HTML content. It allows developers to write dynamic templates that embed Rust expressions and makes it easier to generate HTML content programmatically. It generates efficient Rust code for template rendering at compile time. Take a look at how HTML and Rust integrate. HTML inside Rust: let user_info = v!( name: {user.name} ); v! { {user_info} } Rust inside HTML: @if self.is_logged_in { Hello, @self.username! } else { Please log in to continue. } @for item in self.items { @item } Is this the best library out there? It certainly feels that way to me Crates.io : https://crates.io/crates/rshtml GitHub: https://github.com/rshtml/rshtml Doc: https://rshtml.github.io I'd love to hear suggestions and ideas from anyone interested. Any kind of feedback and support is valuable to me. Thanks rustaceans.

if you want help_me_new to be maximally useful you could do fn help_me_new ( data: &'data [u8], opt: &'helpme mut Option >, ) -> HelpMeHelper as @quinedot said, &'a mut Foo is almost always wrong. the HelpMeHelper must be bound by the lifetime 'helpme , because after 'helpme has expired the HelpMe referred by the HelpMeHelper may be destroyed, for example by calling option = None

As an update, I've managed to get the build system to emit the desired symbols for both debug and release builds by defining the function as extern and re-exporting it through cxxbridge : #[link(name = " ", kind = "dylib")] unsafe extern "C" { #[link_name = " "] pub unsafe fn emit_register(reference: *const c_char); } #[cxx::bridge] pub mod ffi { extern "Rust" { pub unsafe fn emit_register(reference: *const c_char); } } I also removed the link_lib_modifier("+whole_archive") directive in the hopes that doing so would lead the linker to use the dynamic library as a source for the symbol, though this did not work and the symbol is present only in .text . Although very ironically, the throwaway symbol emit_register is now in the relocation section: Relocation section '.rela.plt' at offset 0x42f470 contains 326 entries: [...] 0000000000c58458 000012e300000007 R_X86_64_JUMP_SLOT 00000000005d7760 cxxbridge1$200$emit_register + 0

I am trying to rotate a image from the middle, which fills scthe screen as my mode 2 does for multiple images already. I can't figure out what logic error I am making. Code (click for more details) Output (click for more details)

There's a few approaches, but currently the two main options are some version of shadow maps or ray-traced shadows. Assuming you don't have a ray-traced setup, you'll be doing shadow maps, which can get arbitrarily complicated (eg Unreal Engine 5's virtual shadow maps), but the basic idea is pretty simple in theory : For each light: Render to a 1-channel depth texture (the shadow map): Camera at the light position Use a perspective projection containing the scene Write the depth to the texture if it's nearer Render to the output: For each light: Determine the current pixel location in world position From that, get the distance to the light and position in the shadow map If the distance is greater than the stored depth, you're in shadow, continue to the next light Add the light's contribution as usual Render as before with the total light contribution The devil, as usual, is in the details: there's a lot of subtle maths and traps that can trip you up. Fortunately, WGPU provides a complete, self contained example you can follow along with: github.com wgpu/examples/features/src/shadow at trunk · gfx-rs/wgpu trunk/examples%2Ffeatures%2Fsrc%2Fshadow A cross-platform, safe, pure-Rust graphics API. Contribute to gfx-rs/wgpu development by creating an account on GitHub.