Here is actually a quick screen capture of how my app for creating and visualizing volleyball schemes works.
Implementation details here: https://www.facebook.com/raufaliev/posts/pfbid0njrqH8oLcWGFsZcgE5o2pj3NcDNaYSQeCMY6twXNbZn6dc38m9kjhsBqA4YsMozcl
What I did on the plane to/from vacation and sometimes in between: 3D visualization and editing volleyball schemes for Nadya (she’s a coach). This court in the attached image freely rotates, players can be placed on it, and the ball and player paths are shown – all in 3D.
The ball’s trajectory is calculated so that it does not cross the net when moving from A to B (Bezier formula). Players can take several poses – right now there are hastily made poses for serve, attack, block, pass/receive. Interestingly, in the code: I had to write a bit of “volleyball brains”. The system itself calculates the ball’s trajectory through Bezier curves so that it always passes over the net. Moreover, the height of the launch depends on the type of action: for an attack, the ball “launches” from a higher point than for a pass. I also added auto-rotation: the 3D model itself turns its face to where, according to the scheme, it needs to pass or run.
The longest and most difficult task was creating the 3D model of a female volleyball player. To generate a realistic volleyball player, I used the tripo3D service. It gave me a model in a neutral pose (for free). Theoretically, you can then use Blender and the Rigify plugin to attach an armature to it and move its arms and legs, which would recalculate the model.
However, in reality, this approach does not work well: the AI-generated model contains a large number of geometric errors, which the renderer forgives but Rigify does not. They can be roughly divided into two types — incorrect polygon normals and issues with non-manifold geometry, which are significantly more challenging to fix. Inside the body, there may be “floating” clusters of polygons or intersecting surfaces. When Rigify tries to calculate weights (which bone affects which part of the skin), this internal noise confuses the algorithm, and as a result, the weights are distributed chaotically (for example, moving the arm might start pulling the mesh on the stomach). Plus, the model is slightly asymmetrical.
Non-manifold is a geometry error where the topology of an object ceases to be correct in terms of a three-dimensional body: edges may belong to more than two polygons, polygons may only touch at vertices or edges without a common volume, and “hanging” surfaces or zero thickness may appear inside the model. Such geometry formally does not describe a closed volume, causing problems with rigging and deformations. Moreover, the model needs to be simplified because millions of polygons are not needed for rendering in real-time in a browser.
I fixed these using MashLab, additionally refining by hand (“with a file”). In the end, the model turns out slightly different from the original almost everywhere. The original model had “skin” in the form of textures – the face, shirt, and shorts had to be colored. How to transfer all this to a simplified model? For that, there’s a special operation in Blender called Baking. This also involves some tricks. In the end, it didn’t transfer perfectly, but perfection isn’t necessary yet.
Next, we attach the armature to the “joints”, and after about three hours of figuring out why everything does not work as it should, it finally worked. I made four poses, and now each circle (player) can be told which pose it is in.
I’ll also need to make dynamic changes to the uniform colors – that shouldn’t be difficult. There’s also an idea to transfer poses from photographs – this is more complicated, but generally feasible. Using MediaPipe/AlphaPose, you can detect key points in 2D, then some models like HMR/HybrIK can “lift” flat coordinates into 3D space, outputting relative joint rotation angles. The resulting data can be attempted to be projected onto a Rigify skeleton. Since the proportions of the generated volleyball player and the person in the photo may not match, that’s exactly why Inverse Kinematics (IK) is used. This part is quite complex, but overall it’s not strictly necessary – just interesting to figure out and make something functional.
Video in the comments
How did we ring in the New Year? In an empty movie theater watching Avatar IMAX 3D.
The CGI is simply stunning. Seriously, it might be the most photorealistic film in history from a computer graphics perspective. The detail in individual faces—there were times I could swear I was looking at human faces painted (and that’s a compliment). And there’s a lot going on in the background too. You really need IMAX and ideally 3D because it’s one of the few movies where IMAX 3D technology isn’t just used in certain scenes, but everywhere.
The main villain Varang is absolutely amazing. Every time she appeared on screen, she stole the spotlight. Despite the CGI, they perfectly conveyed all the complex emotions of her character. They made her truly merciless, sexy, and dangerous. It turned out cool.
The three-hour runtime is densely packed with action, with practically no scenes that make you want to yawn.
Wow, they really think that “we” have been together for 19 years and for me, this is a new achievement.
Tomorrow is the flight to Costa Rica, and here I am creating (or created) a volleyball playbook editor for Nadya. As a coach, she prepares for her sessions and leaves behind hundreds of pages of text with diagrams on each page. The text is handwritten, and theoretically, it’s simple to convert to a digital format, but converting the diagrams into high-quality vector format is exhaustive—there are so many. So, I decided to make the software yesterday. And today, the first version is ready to use. This is a diagram editor, somewhat remotely similar to a diagram editor. Also got to dig into the fabric framework.
The process looks like this. Gemini/ChatGPT through an API can convert hand-drawn diagrams into a structure that my program understands. Then we open this file in the program, and tweak a bit if necessary. Or maybe even redraw from scratch – for simple diagrams, it’s even easier. There are four types of objects – player, cone, target, text. Any can be connected with arrows, solid or dashed, labeled with text or numbers or not, in any chosen color, straight or curved. If you touch an object with the mouse, all connected arrows will follow.
The result can be saved in a file. You can open a template and based on it create something new. You can generate a Python script – yesterday it was still relevant, today generally not needed anymore – high-resolution SVG/PNGs are made directly from this app (yesterday they were made separately in Python).
It’s clear why you wouldn’t just ask Gemini/ChatGPT to do something for ready-made vector editors: firstly, they are too flexible and limiting LLM’s imagination is quite difficult. As a result, you get stylized, unusable images. Here, instead, there is a framework consisting of four objects and that’s all, LLM knows about it and only generates what can be represented with them. Secondly, this framework operates with objects, not elementary vector primitives.
Overall, this is the first step towards my idea of an automatic diagramming system based on descriptions. Where you give an LLM a diagram description, and it consistently generates what is written in the description, and if you make any corrections, they will be taken into account during regeneration.
Everyone is waiting for a cyberpunk future where each cafe table is served by an android. But it seems that it will never happen. The automation of the service sector is stagnating and will continue to do so for one simple reason: maintaining a human is becoming cheaper than servicing an industrial robot.
Food and clothing are rapidly depreciating. Production volumes are such that feeding and clothing a “bag of skin” today costs pennies. Now compare this with the cost of developing, software, and maintenance of a complex robot waiter or cleaner. A human is a self-regulating system that fuels and updates itself. And if worn out, easily replaced. Pure economy!
In the “First World,” the motivation to labor hard will disappear. Why go to a hard, boring job if basic needs are met with minimal effort, and everything else is done by others who really need to? People in developed countries will work only where there is thrill and pleasure. Eventually, we will face a shortage of hands where it is “not cool,” but there won’t be robots there either – too expensive.
Poor countries will be stuck in the past. Their populations are growing like yeast. Choosing a job there is a luxury available only to a few. An excess of labor makes work almost free.
I think the world is facing a harsh imbalance. Developed countries will likely permanently close their borders to avoid diluting their comfort, and all industries that are still difficult or expensive to automate will simply move to poor regions. Perhaps, developed countries will become less likely to conflict with one another, as there will be too many resources to make every resident happy.
But it will be harder with poor countries. Why invent a complex robot if you can relocate a factory where thousands are ready to work for food, which becomes cheaper every year? This has long been happening and will most likely continue for a long time.
Conventional programmers in the USA won’t be replaced by AI, but by programmers from Southeast Asia and South America. Several layers of AI for quality control and one manager approving AI conclusions and automatic layoffs and hiring will oversee them. And those programmers who remain in developed countries will focus more on orchestration than on coding. This role requires even more intelligence, and only one in ten current individuals will be capable. Only, the reason for such a crisis will not be AI.
Also, I think that the borders of the future world may close in one direction. It will become increasingly difficult to enter developed countries from developing and poor ones, but the opposite will be facilitated by authorities. Africa is growing so fast that it will surely become a problem if people there are not already prepared for life beyond their villages.
The future is not about the uprising of machines. It’s when some work for pleasure, and others because they are cheaper than electricity and gears.
Do you agree, or am I exaggerating too much?
Nadia and I tried out the Aescape robot massage. Well, I was interested to see the technical side of it all. Overall, it’s quite interesting, but driving 45 minutes instead of 15 to get a robot, even if it’s slightly cheaper… not sure it makes sense to go there regularly. It’s a different story if you’re already at the gym and want a massage right now, without an appointment – it’s like a deluxe massage chair. Yes, in that case, it’s exactly what you need.
The system scans the body with four cameras on the ceiling, creates a 3D model, and then on the whole, the robot arms do a pretty good job of kneading the muscles just right, stronger in some places, gentler in others – considering the overall anatomy, and the specific person on the table. Some might wonder, won’t they accidentally maim someone due to some bug, but we drove there and back on Tesla’s autopilot, and if the cars were going to kill us, they’d have had an easier chance.
We’ve all encountered it — the “Main Excel Spreadsheet Managing the Business.” The very one B2B companies use to calculate million dollar quotes. It has 12 tabs, 1000+ nested formulas, and zero documentation. For ten years, it had “quick fixes” slapped on and constants hidden away. It’s no longer just a file, but a living organism that no one fully understands except for the guy who quit years ago. That’s how puzzled I was. Moreover, there was uncertainty whether even half of the formulas were needed, or if they were vestiges of the past.
Typical cell:
=IF($D11=$D10,””, IF(ISNUMBER( INDEX(Data!$T$10:$U$17,
MATCH(TabCalc!$F11,Data!$T$10:$T$17,0),2)),
INDEX(Data!$T$10:$U$17, MATCH(TabCalc!$F11,Data!$T$10:$T$17,0),2),
INDEX(TabProd!$C$8:$U$112,TabCalc!$D11,I$1)))
I was tasked with transferring this logic into code so that it was all computed by software. The Excel file seemed to have everything it needed, but in reality — it was a complicated black box. 1069 formulas.
The challenge was in how to translate a thousand interdependent formulas into clean code without losing any edge cases.
Here’s what I ended up doing.
Instead of rewriting everything from scratch at once with uncertain prospects of bug proliferation, I used a strategy of lazy computations and mocks.
I built a structure on Groovy that mimicked Excel’s behavior. Each computation (from a cell) I defined as a function that executed only when it was called. And the functions were a multidimensional dictionary.
I started from the end of the computation graph: from results to inputs. If a formula depended on something I hadn’t yet written, I “mocked” it in the code, simply substituting the value from the Excel sheet.
Bit by bit I replaced these mocks with real logic. Comparing the output of my code to the Excel at each step, I could clearly see where my logic diverged.
In other words, I moved from the result to the input data. At each step, it was clear which mocks needed to be turned into code, and I could compare version +1 with version -1 — the result had to match. As soon as all mocks were replaced with calls — the task was done.
The real “secret ingredient” was the dynamic nature of Groovy for creating a multidimensional map of functions. Instead of static variables, I used a deeply nested structure, where each “leaf” was a closure. This allowed access to any part of the table — be it an input parameter, a config constant, or a complex intermediate result — through a simple, unified syntax, and some components were dynamic.
Here’s an example:
conf[“group”] = { x -> [“a”, “b”, “c”] }
conf[“group”]().each {
calculate[“Group”][“Subgroup”][it][“TotalQuantity”] =
{
x -> calculate[“Group”][“Subgroup”][it][“Someparameter”]() * conf[“someConstant”]()
}
}
Using dynamic keys and closures, I could iterate through product groups or data sets. Since these were dynamic functions, not stored values, the entire system worked like a living graph of dependencies.
Testing was possible right from the start of transferring the formulas. The charm was that you were kind of addressing a cell through syntax like calculate[“Totals”][“A”](), but in reality, you were launching an entire tree of calculations at that moment. And this was incredibly convenient for debugging.
In two weeks, the “Black Box” was transformed into a transparent, modular library with clear logic, which produced exactly the same result as the original table.
P.S. Of course, all the data in all the screenshots are thoroughly obfuscated, or rather, written from scratch for this text.
Oh, I just solved a really cool problem. It’s tricky to explain though. But I’ll try.
So, the client has 10 search websites. They all use one index but throw different queries at it. To what the user enters, a very long and complex query is added, generated by a module on Sitecore. It includes template and page IDs that need to be included or excluded. Ultimately, it’s impossible to understand what’s going on there. There could be ten opening brackets and some randomly closing ones, but it worked with Coveo. Reformatting helped, but not much.
And each site has its own version of this. Meanwhile, the same IDs appear periodically. I first tried to manually figure this out, but it was a nightmare. Nothing helped. There are also nested conditions. For example, “exclude this template” not globally, but only if that field equals one.
Here’s what I did:
I wrote a script that parses this textual “mess” into an abstract syntax tree (AST). This allowed to turn an unreadable string into a structured JSON object, where it’s clear: here’s AND, there’s OR, and here — a specific condition.
Then I turned these conditions into Boolean algebra formulas. Using the SymPy library, I “fed” these formulas to simplification algorithms. Mathematics itself eliminated duplicates, collapsed excessive nesting, and removed conditions that are logically absorbed by others. As a result, the “trees” became flat and understandable.
In the attachment — the original tree and the simplified one.
To be sure that I didn’t break anything during simplification, I wrote a test generator. It takes the simplified logic, puts it back into a working curl, and checks whether the number of found documents (totalCount) matches the original request. The numbers matched — meaning, the logic is preserved 100%.
Having simplified and standardized structures for each site in hand, I built a comparison matrix. The script analyzed them and highlighted Common Core — conditions that are guaranteed to be required (or prohibited) on all sites without exception, and Specifics — unique “tails” that distinguish one site from another.
In the attached screenshot: REQ means that the condition is guaranteed to be met for any document that goes through this request. NOT — definitely not met. OPT — the condition is present in the request, but it’s not strict by itself. It only works in conjunction with something else. “.” — the condition is not mentioned in the request at all.
For 3 sites it responds instantly, for 10 it takes about 30 minutes.
And of course, all data in all screenshots are thoroughly obfuscated.
I’m checking out what open data we have in our county to play with data analysis over the weekend, and discovered, for instance, an open database of all 1.5 million trees in the county. The screenshot shows just a tiny part around my house.
Hi, I'm Rauf Aliev. 