The last release (1.5.3, April 2023) has started to show its age with recent Home Assistant versions (editor drop-downs that don’t open, preview refresh not working in section views, crashes at startup…), so I made a fork that updates the libraries and fixes these problems. It’s a drop-in replacement: existing configurations keep working as they are.
What’s new
New visual editor, built on Home Assistant’s own components: settings in sections, lists of entities, object groups and views that you reorder by dragging, a page for each entity showing only the options of its type, and warnings when an entity or an object doesn’t exist. You can pick an object by tapping it in the preview, and the objects of the item you’re editing are highlighted. The YAML it writes is much shorter (no empty blocks, no default values).
three.js 0.186 and Lit 3: physical lights and tone mapping. Shadows are redrawn only when something changes, and nothing is rendered while the card isn’t visible (much lighter on phones).
Person trackers for presence radars like the HLK-LD2450, a TV screen that lights the room with the colours of the picture, an animated shower, info boxes and a Views menu.
Many bug fixes, including some from the original card (the camera light always pointing at the centre of the model, removing a zoom area in the editor wiping the whole list, …).
Install: HACS › ⋮ › Custom repositories › https://github.com/giosci1994/floor3d-card, type Dashboard (it has also been submitted to the HACS default list). If the original card is installed, remove it first: both define custom:floor3d-card.
UPDATE: floor3dx-card 1.4.0 — Added visual editor built on Home Assistant’s forms
Credit first: the editor in this release is the work of @giosci1994, from the giosci1994/floor3d-card fork (MIT). I adapted it to floor3dx-card’s options and types. The editor framework, the pick-and-highlight link to the preview, the config normaliser and the wildcard object ids are his; the forms themselves, every section and type page, the daylight panel and the card-side wiring are written for floor3dx-card’s own options.
Settings in sections: 3D model, camera, light and shadows (with the daylight block), interaction, rendering. Switches are toggles; each field’s help text gives the default.
Entities, object groups and views as lists you drag to reorder. Each opens its own page showing only the options of its type. An entity line warns when the entity does not exist or its object is not in the model.
Object menus list every object of the loaded model, with search. The pick button turns the preview into a picker: tap an object and the field fills; for a group, taps add and remove. The objects of what you are editing are outlined in the preview.
Use the current view copies the preview camera into the initial view.
Object ids may contain *: Lamp_* is every object whose name matches, in entities and groups.
The YAML it writes is tidier: no switches at their default, numbers unquoted, group objects as plain ids. Hand-written YAML, including the parts the editor does not cover (daylight.windows, exterior, glow, image.url state maps), passes through untouched.
On a Home Assistant without ha-form, the previous editor appears instead.
I’ve released Home Scheduler & Simulator, a companion integration designed for the floor3d family of cards. It provides a sandboxed ecosystem for configuring your 3D home model, editing schedules in a weekly 15-minute grid, and previewing an accelerated day before enabling real device control.
It includes an embedded model editor and supports lights, switches, fans, blinds/curtains and other covers, plus scene activations. So far, it has only been tested with floor3dx.
Hi
great things what you show.
However, I have some issues with configuration, maybe can enlighten me.
I use this project since quite some time, starting with the original floor3d-card from adizanni.
While playing around with all the forks I managed to get a had nice setting where the sun came very nicely through the windows and created crisp shadows on the floor, while the environment stayed relatively dark.
Unfortunately I lost the setting and now Iam no more able to reproduce. Tried all forks, and various settings but no luck. I guess meanwhile I tried all parameters.
I always get more or less blur environment with the color following the daylight, but no more the nice sunbeams, as I had before.
This is the setting, please somebody guide me to bring the sunbeams back.
thx
Bernhard
I’m guessing the sunbeams you remember come from the real sun: sky: 'yes' puts a directional light where sun.sun says, and with shadows on the ceilings and walls of the model block it, so it only reaches the floor through the windows and you get crisp patches. Three things in your config stop that from happening:
shadow is not set, so it is 'no'. Without a shadow pass nothing blocks a light in three.js: the sun lights every surface it faces, through walls and all, which is the even, flat look you are seeing. Add shadow: 'yes'. This is the one line that matters.
daylight and sky together.daylight is for plans without a roof: it fakes time of day with a tinted ambient, a hemisphere light and one spot per window, and it tints the whole environment with the sun’s colour. That is exactly the “blur environment with the colour following the daylight”. Your model has levels and ceilings, so you do not need it: remove the whole daylight: block and let the real sun do the work. (Also, object_id: '47_7' under windows is the object name from my example, not one from your model, so that spot was never created.)
globalLightPower: 2. That is the light that follows the camera, default 0.2. At 2 it washes out everything the sun does. Bring it down to 0.2 to 0.4.
If the sun still floods rooms from above, the model needs something over them: either show the ceilings in Sweet Home 3D before exporting, or add a transparent box over the floor named transparent_slab as the original card documents. For a dark environment with bright beams, keep globalLightPower low and let the shadows do the contrast.
Hi
thx a lot.
"shadow:‘yes’ does the trick.
I was forced to disable it because it collides with something in my “lights” configuration.
Once shadow globaly enabled, the whool plan disapeared, thats why it was of (without really knowing what it is good for…).
This morning I removed all lights and used your sample config - bang - the light comes now through the windows. Exactly as I want.
Now have to try&error to find out which part in the configuration killed the rendering.
thx for your help - and great work from all of you
Bernhard
Update: Can it be that the “floor3dx-card” need more resources or so than the “floor3d-card” from user giosci1994 Giovanni ?
Now I have a yaml which renders totaly fine with Givannis version.
But does not render with the x-card version. (black screen)
To make it render I must either set “shadows: no” or remove the amount of lights (~20 light entities each consist of up to 5 spots). The lights itself have 100% identical configuration I compared several times. Only add/remove one of them makes the card rendering or not. There is no error msg, and no console error log. It is not browser dependent.
Not resources in the sense of CPU or memory: a GPU limit. Every light that casts shadows needs its own shadow map, and each shadow map takes one texture unit in the shader. A GPU exposes a fixed number of texture units to a single material, 16 on most phones and integrated graphics, 32 on many discrete cards. When the scene asks for more, the shader fails to compile and three.js draws nothing: a black canvas, usually with only a quiet warning or none at all. That is why removing one light, or turning shadows off, flips it from black to working, and why the configuration of the lights themselves makes no difference.
Twenty fixtures with up to five spots each is around a hundred lights, far past the limit on any GPU. Giovanni’s fork handles this explicitly: it counts shadow-casting lights, stops at the GPU’s limit, and lets the rest render without shadows (the sun first, then the lights in order). floor3dx-card inherited floor3dpro’s handling, which does not enforce that cap reliably, so the same YAML blows past it. I will consider porting a cap in the next release.
Until then, two changes get the same scene rendering with shadows on:
One light per fixture, not five.light.light_object creates a single light on a named part of the group, and the whole group stays clickable:
- entity: light.living_room
type3d: light
object_id: <living_room_spots>
light:
light_object: spot_1_1 # one of the five
lumens: 2500 # raise it, since five lights became one
shadow: 'yes'
Shadows only where they show. Put shadow: 'no' on every light entry whose shadow nobody would notice (ceiling cans in a corridor, under-cabinet strips) and keep 'yes' on the few that cast across a room. With shadow: 'yes' at card level, a light with shadow: 'no' still lights the room; it just casts no shadow and costs no texture unit. Ten shadow-casting lights is a safe ceiling on a phone.
extralightmode: 'yes' was meant to help here, counting only the lights that are on, but it can still exceed the limit when enough of them are on at once, so do not rely on it alone.
Ahhh, very helpfull information.
This clarify a lot of fancy behavior I noticed in the past, also with all the other forks I had tried meanwhile.
This information should be put to the manual, because normal user are not aware about the side conditions and behaviour.
You explained it very well, thx so much.
The main reason why I have configured most lights with shadow: ‘yes’ is to prevent the light from traveling through the walls.
