All sources point that their 2025 models are still using brushed rotors. Here is a teardown video it's from Nisan car but it's using a Renault electric motor https://www.youtube.com/watch?v=BFmp9ODkCA8 .
In the picture at Renault website (section describing their next gen 2027 motors) you can clearly see the 2 slip rings on right side. That might be just a placeholder using their last gen motor, but I would expect that they would mention it if their next gen was brushless while the current one has brushes.
Brushless seems to be a thing that they have described as future work for at least 5 years but it's not there yet.
Did anyone commenting about Qt and how it makes sense actually looked at the result?
I don't think any of Qt default themes in last 10-15 years have looked anything close to that. With all those gradients and gray rectangular boxes it's more like a parody of early 2000s x11 theming and Flash based UI frameworks. My personal expectation when hearing QT style would be more like the builtin Fusion style.
If you ignore the central part with gradients, right side with square 3d boxes look a bit like classic win32 style (which would also be what QT used on windows by default) but you wouldn't normally end up with so many nested raised 3d boxes (or visible nested boxes in general). Buttons (and other clickable subcomponents) are raised, tabs are raised, but UI group elements have more of recessed border and you would use it sparingly. Often you would have just a separator line or empty space for grouping elements in flatter UI hierarchy.
Qt is GUI framwework for C++. How would having a bunch of C++ code containing barely any styling in training material help styling a website? Also the whole point is that it's a style that you don't recreate it hundred times it's what you get automatically by letting the GUI framework and theme engine do it's work. The modern Qt with Qt Quick/QML and it's flavor of CSS is closer to web development but those kind of Apps lack any kind of characteristic QT style since the authors are more likely to build the styling from scratch (resulting in one of those UIs with random image in background and hardly recognizable widgets) or based on builtin Qt versions of Google/Windows/Apple style guides. Wouldn't expect any modern QML based app to look like the obtained "Qt" style.
In the traditional desktop apps based on QtWidgets, you can customize the style with css but the hard coded logic within the theming engine (implemented as native dll) is equally important for the look, not everything is is defined by css. You have to do either very little customization (minor styling for individual special elements maybe a color pallet swap) or override everything, otherwise it's easy to end up with ugly, broken result. Typical problems being Qt changing default base theme based on platform, theme engine switching to fallback rendering path once you override certain style properties.
Another important aspect of the classic desktop look which doesn't really translate well to websites is the set of widgets. Frameworks like Qt(widgets) provide reasonably wide range of widgets and you would use them as is. Unless you really needed it rarely would you create a widget from scratch or recreate what's already available. You wouldn't recreate a button, checkbox or a dropdown(combobox) using bunch of divs which can't be said about the modern web design. You might customize the behavior of builtin widget with subclassing or by combining multiple builtin widgets. The API for drawing custom widget from scratch is a pain and using it correctly to properly integrate with theme engine is even bigger one.
The problem here wasn't that frames in single animation had different sizes, but separate animations. The example images are a bit misleading since they show only one frame from each animation.
Every animation tool will provide consistency across frames of single animation, but functionality for aligning and managing transitions between pairs of different animations is less common and more in the territory of game development tools instead of animation drawing.
That's still something the game programmer linking animations together should be familiar with. You could still have artist use single frame size for all animations, but that means having gigantic square many times the width/height of character since you can have some animations which are stretched horizontally and some which are very tall. And if your workflow doesn't include good sprite packing, such gigantic frames can easily become impractical in terms of texture size.
Having the game programmer define single anchor point per animation (assuming aligned frames within each animation) doesn't take much time at all. You wouldn't want to realign individual frames within each animation (that's part of artistic intent and artist should do at least that much), but even that would take order of magnitude less time than the process of drawing those frames.
There are still times the programmer might have to go through each frame defining anchor point/hitbox, when artist picked a wrong config during export producing packed sprite sheet and there is no time to reexport it, or when dealing with animations that mix animated and software driven movement like large jumps.
In every game I've made, I've had a resolution set for characters. Resolution is consistent across animations. It's week one gamedev stuff. Feels like Claude should've picked up on that, but clearly the 1 trillion they've put into it already hasn't made it as competent as the typical 14 year old noob dev.
Flipper zero was an arduino with half a dozen sensor, radio and other communication modules. Flipper one is a laptop/mobile phone class system in weird form factor no doubt its going to be more expensive. No point even comparing them. You can't call it a price hike if it's completely different category of product. There have been plenty of openish tinkerer laptop/mobile phones projects to know that paying high end laptop price for a device with compute power of last generation raspberry pi is a likely outcome.
>Flipper one is a laptop/mobile phone class system
This isn't true it's more like a modern Rasbperry Pi 5 level system with half single core performance and relatively similar multicore.
The exciting thing about the system isn't the chip it's the connectivity, form factor and extra hardware around it. But let's not pretend it's comparable to the power of phones and laptops which are way ahead.
Although with inflation and supply chain issues I'd be shocked if this ships under $450, but if they pull it off I think you'll get your moneys worth compared to comparable Pi setup.
When comparing signed and unsigned integers of same size the signed one will be converted to unsigned. In a reasonably configured project compiler will warn about it.
In case of integers smaller than int, promotion to int happens first.
In case of signed and unsigned integers of different size, the smaller one will be converted to bigger one.
> Hardware and software that belongs to everyone. Waiting to be OSHWA certifie
> Hardware & Industrial Design All rights reserved. The hardware design, including but not limited to Are proprietary and the intellectual property of Juan Ramón. No commercial use or reproduction of the hardware is permitted without express authorization.
Same for software, the comparison table says MIT, other parts say GPL v3.
Also the whole concept of exam mode which is in any way effective seems contradictory with GPLv3. Any hardware means which would limit the ability to use modified version of software would violate GPLv3.
Even if you are completely skeptical about the AI cad model generation they also demonstrated their representation for model search/matching. Having a smarter search method for cad models based on 3d geometry in addition to traditional text search would be nice to have.
When skimming a research paper in addition to abstract don't forget to read "limitations and future work" and "conclusions".
In the limitation section they are quite direct with it: "images used .. are mostly isometric and noise-free CAD-images" and "limited CAD vocabulary used in this study needs to be extended by including more sophisticated CAD tokens such as revolve operation, edge operation (e.g., fillets/chamfers)". It currently supports only series of pads (can be subtractive). Many simple beginner exercises of seemingly similar complexity don't fit those constraints. Some of the parts shown could be more naturally created using wider set of tools, but technically can be created using only pads.
So even if you tried with clean screenshot of simple 3d model, it will likely fail if camera settings aren't right, and it will fail if model can't be represented using series of pad operations. Anything containing spheres, cones, nearly all lathe parts, fillets which can't be included in 2d sketches will fail. In theory arbitrary extrusion angles are supported, but all examples showed only axis aligned parts.
That said I wouldn't be surprised if it failed even if you considered exact limitations not just similar complexity in your attempts.
Assuming images in the googledrive are the training data, "mostly isometric and noise-free CAD images" is a bit of understatement. All of them are at very specific angles using and single style. Specific solid gray infill color for "images", and white infill with weird shading around perimeter for "sketches". Both with white background and pixelated non antialised 1px lines. No reason to expect it capable of processing anything which doesn't have exactly same visual style. For practical product that would have to be solved but that wasn't really the point of this research. All the style transference papers have show that it's more or less solvable problem, but for a paper exploring what model architecture and 3d representation could work best for AI cad it seems like unnecessary distraction that would only bloat the training costs and time. Most annoying part is that it makes hard to test the model with your own inputs.
This isn't B-rep based modelling. Far from it. It builds up the feature tree and then uses geometry kernel to generate B-rep based representation. The final generator output script could probably be adjusted to generate openscad. It only supports 2d drawings containing lines, arcs and circles and extrude operation for making them 3d. Operations like fillets and chamfers which depend on intermediate B-rep model state are not supported.
I would even argue that for basic modelling majority of tools/features in CAD operate at the abstraction closer to CSG for describing what and B-rep is only treated as how. Just like good chunk of code based CAD use combination of CSG for what and triangle mesh based geometry engine for how. That's assuming you consider standard 2d->3d operations (extrude, revolve, sweep along arbitrary 2d profile) as valid primitives for CSG.
User comes into direct contact of B-rep in very specific situations: 1 doing operations like fillets/chamfers/draft/thickness based on intermediate geometry, 2 attaching sketches or other features to generated geometry or using generated edges (instead of new sketches) for guiding operations like complex sweeps, 3 surface based modelling workflows where you build up the the solid from individual faces typically including complex curved surfaces.
In case of 1 and 2 the the dependency on b-rep based representation is only marginal, in theory you could select edges in triangle mesh based underlying representation but the final result but quality of result wouldn't be as nice and TNP issues for parametric model editing would likely be even bigger than it is for existing CAD. That's not really CSG territory anymore but isn't exclusive to B-rep either, and involves a bunch of work that's outside the scope of B-rep. In non parametric mesh modellers with more destructive editing workflows like blender chamfers and fillets work fine. And if anything for reliable parametric models you often want to limit dependencies on intermediate geometry as that depends on CAD keeping track of where each edge/face originated from outside the b-rep and increases the chance of TNP issues.
3 is critical for industrial design containing large amount of complex curved surfaces like cars and other consumer products, but there are also many more technical parts where it can be completely ignored. Cad tutorials for beginner tutorials almost completely ignore this category of cad modelling. The part about not being exclusive to b-rep also applies for surface modelling part.
The same rule which makes the evaluation order of a++ + ++a unsequenced also applies to (x+y+z+a+b+c) where x,y,z could be any expression (in a sane case on separate variables and without mix of pre/post increments). Breaking questionable code and introducing UB where reordering changes result is just a side effect of this.
Just switching between left to right or right to left wouldn't be that useful but it also permits to interleave the subexpression evaluation. Grouping memory fetches/writes, taking into account how many execution units and registers of different kinds a CPU has can have some performance benefits.
For example if you have something like `++a[0] + ++a[1] + ++a[2] + ++a[3]` instead of evaluating each increment one by one both GCC and Clang will vectorize it loading all 4 values from memory using single simd instruction, incrementing and then writing result back to memory. And if you add fifth one (but not 8) which needs to be handled using regular instruction, that will be done after the first 4.
If standard defined that left subexpression of addition is fully evaluated before the right expression that wouldn't be allowed.
In the picture at Renault website (section describing their next gen 2027 motors) you can clearly see the 2 slip rings on right side. That might be just a placeholder using their last gen motor, but I would expect that they would mention it if their next gen was brushless while the current one has brushes.
Brushless seems to be a thing that they have described as future work for at least 5 years but it's not there yet.
reply