Magnifique 
La transparence, ça doit dépendre de ce que tu as choisi dans OCL.
Mais Layout ne semble pas vouloir la conserver à l'affichage quand on choisi le rendu en "Vectoriel". La transparence ne se voit qu'en "Tramé".
Que veux tu dire par "voir à l'intérieur" ? A l'intérieur de quoi ?
Buenos dias,
Lo sentimos pero los establecimientos de fabricación de muebles no pueden figurar en este catálogo.
Buenos dias,
Lo sentimos pero los establecimientos de fabricación de muebles no pueden figurar en este catálogo.
Ok, comme tu veux.
Layout permet tout de même de faire des mises en plans bien plus intéressantes et faciles à imprimer que les simples côtés dans le modèle 3D.
Et mixer à la fonction de dessin d’OpenCutList, c’est rapide d’extraire la portion que l’on veut vers Layout.
Il est aussi possible de changer le nombre de segments en sélectionnant les entités cercle ou arc depuis le panneau "Infos sur l'entitié"
Défi : Comment trouver analytiquement l'approximation d'une Ellipse par une série d'arcs de cercle ?
Hey les gars commencez pas l'année en vous bouffant le nez. Paix et amour 
. Restons-en là !
ourea, ta remarque est fondée. Mais, j'ai posé le problème ainsi, parce que c'est ainsi qu'il est à résoudre. En occulter un bout (même s'il parait évident) produit pas un résultat valable. C'est toujours dans les trucs faciles qu'on écarte qu'on fera le plus d'erreur.
Pour preuve, mon algo actuel donne des effets de bord que j'explique mal pour les ellipses qui ont justement ... un angle...
Par ailleurs, cette question étant destinée à survivre dans le temps à mon besoin, je serais content qu'elle apporte une réponse générale.
Kentaro, chacun ses évidences.
ourea merci d'avoir regardé. J'ai trouvé mon problème ! Il venait en effet d'ailleurs. J'ajoutais 2 fois l'angle d'inclinaison ... 
Plus il y a de gens, plus il y a d'idées 
une solution optimale nécessite une approche itérative, ce qui n'est pas ce que vous voulez, j'imagine ?
J'ai pas de frein à ça tant que ça fait pas des calculs de 10min.
Belle année à toi Sam.
mofran le SVG supporte très bien tout ça et OCL exporte aussi en SVG.
Le DXF reste malheureusement un standard universel dans les logiciels métier et autres machines d’usinage.
DXF supporte les splines, mais à ma connaissance ça ne mixe que des courbe de Béziers sans cassure de courbe.
Oui DXF n’est pas le format qui va bien. Je le comparerai bien au système impérial qui rend les américains fiers et qui est merdique à implémenter dans du code. Grosse perte de temps.
Bref, vive le système métrique et les standards ouverts !
Il y en a plusieurs et avec chacune avantages et inconvénients du différents.
Je vais panachez ce qui a été proposé ici et je vous donnerai la solution retenue.
Cool, si ça te sert. Par contre, pour ne pas se trouver submerger de notifications, pour l'instant, seuls les notification que j'ai jugé "principales" sont envoyée par ce moyen (Nouveau coups de coeur, Nouveau message privé et nouvelle réponse à une question). A ce que tu me présente de ton usage, j'ai l'impression qu'il t'en faudrait plus, non ;) ?
Salut ecto1, merci de cette intervention intéressante.
n'y a t'il pas un risque que les gens se détourne d'aller sur l'air du bois
En fait, je pense que ça aurait l'effet contraire. La notification ne peut pas donner beaucoup d'info (texte limité) et donc c'est indirectement une invitation à en rechercher plus.
C'est une approche personnelle, mais je trouve que cela détache un peu du site, non? et peut-être un peu intrusif....
L'ultra connecter n'est en effet pas une chose que je vais défendre. Et donc pas une chose que je voudrais dans l'absolu pour L'Air du Bois.
Reste que depuis les 5 années d'existence du site, le monde a changé et les gens qui le consultent aussi. Ce site aura beau être au top technologiquement, il ne sera rien sans des vrais gens derrière qui interagissent.
Or, de mon sentiment, la nouvelle génération a été formatée (et je ne parle pas que des ados) ces dernières années par les réseaux sociaux et justement par ce système de notifications. Dans la majorité des cas que j'observe dans l'esprit de l'utilisateur, maintenant, s'il n'y a pas de notification, il n'y a pas de nouveauté.
C'est triste à dire, mais on est devenu dépendant de ce que ces réseaux veulent nous montrer.
Pourquoi le mettre sur L'Air du Bois alors ?
En fait, depuis une paire d'années, je constate un changement des comportements sur le site. Beaucoup, voir énormément plus de visiteurs (env 3000 par jour), mais très très peu d'interactions à proportion. Alors, je cherche des solutions pour que le site reste un espace vivant où les gens parlent et échangent. Bref, qu'il ne passe pas à côté des nombreuses personne qu'il pourrait intéresser.
Des options comme celle-ci sont à mon sens autant de leviers librement actionnables qui peuvent permettre à un peu plus de gens d'offrir les quelques minutes d'interaction qui donne la vie du site et donc les choses intéressantes et donc l'enrichissement de chacun.
Je pense que nous sommes entrée dans un ère du zapping et de l'instantanné. Pas facile de montrer la philosophie du permanant, du Bien Commun dans ce contexte sans essayer de s'adapter, non ?
Après, je suis ouvert aux solutions alternatives. Encore une fois, mon but est que la richesse déployée ici vive et serve largement. Largement, parce que rester une petite communauté, c'est enfermant et voué à s'isolé.
L'idée est d'offrir à chacun la possibilité d'être à son rythme ;)
Ca reste une option ...
L'application mobile à ses travers :
- Il faut redévelopper tout ... et pour chaque plateforme : iOS et Android
- Il faut payer les stores d'app tous les ans pour y rester
- A part les notifications pour les iOS, il n'y a rien sur l'app mobile que le site ne peut pas faire.
L'Air du Bois est déjà responsive. C'est à dire qu'il s'adapte à la taille des écrans de mobiles Et 99,9% des fonctionnalités y sont disponibles.
Le navigateur mobile peut très facilement se faire oublier en mettant un raccourcis vers le site sur ton écran d'accueil.
Avec tout ça, déjà en place, on couvre 99% des apports d'une app pour ce qu'on veut en faire ici. Il n'y aura donc jamais d'app L'Air du Bois ... puisque dans un sens elle existe déjà
Actuellement, c'est possible. Il suffit de changer la masse volumique.
Si ta barre a une section de 100x100mm pour une longueur de 6000mm et elle fait 36,77kg :
Elle occupe un volume de 6x0,1x0,1 = 0,06m3.
Sa masse volumique est : 36,77 / 0,06 = 612,83kg/m3
Pour le moment la masse volumique est définie pour toutes les longueurs et section de la matière. Il faudra faire une matière différente pour chaque longueur si la masse volumique doit être différente.
C’est chouette !
Merci ADPB !
Pas facile de faire un choix quand la solution ultime n’existe pas :)
Salut,
N'est pas plutôt l'agence de Angers ?
Merci ourea !
J'avoue qu'à la lecture le raisonnement semble se tenir. Mais j'ai aucune idée comment le coder et je suis pas certain d'en avoir vu les subtilités.
Je dirai pas non à un petit croquis ?
On calcule la courbure le long de l'arc d'ellipse
et
En chaque point, on calcule le cercle de courbure
C'est pas la même chose ? = rayon du cercle oscultateur ?
Ta proposition se rapproche de ceci, non ?
Merci !
Voici déjà un premier résultat sans interpolation avec 36 points sur une ellipse complète et un échantilon de 1000 valeurs calculées
Je regarderai à faire mieux plus tard.
Mais dans cette façon de faire, il va y avoir un nombre fixe de points quelque soit la longueur de l'arc. Et il n'y a pas forcément de point sur les extremums.
Il faudrait presque toujours faire les calcul sur l'ellipse complète et extraire les points contenus sur l'arc... 
Je voulais dire qu'il n'y a pas forcément de point "clé" sur les 4 "pointes" de l'ellipse (sur les rayons).
Pour la répartition des points une chose qui me semble importante par rapport à l'usage ici est que quelque soit la taille de la portion d'arc à traiter les points choisis se trouvent aux mêmes endroits pour une ellipse donnée.
Ceci afin de ne pas avoir deux formes complémentaires dans le dessin qui ne donneraient pas la même approximation parce qu'elles n'ont pas la même longueur d'arc.
C'est comme dans la vraie vie de l'atelier. Couper une pièce de bois à la côte précise n'a pas toujours d'intérêt, mais tout couper à la même taille, oui.
Exemple dans le cas suivant :
Sais-tu "détecter" les formes complémentaires ?
Oui et non.
Il y a juste que dans l'exemple donné, ma détection donnera naturellement la même ellipse pour les deux arcs.
C'est vrai que le résultat est étrangement décalé.
Voici le code à coller dans la console SketchUp pour afficher ces points :
a = 5.0
b = 3.0
def point_at_t(a, b, t)
Geom::Point3d.new(a * Math.cos(t), b * Math.sin(t))
end
def curvature_at_t(a, b, t)
(a * b) / Math.sqrt((a**2 * Math.sin(t)**2 + b**2 * Math.cos(t)**2)**3)
end
def point_at_dk(a, b, ts, dks, dk)
i = dks.find_index { |v| v >= dk }
point_at_t(a, b, ts[i])
end
ts = []
ks = []
# Compute curvatures
key_count = 1000
(0...key_count).each do |i|
t = 2 * Math::PI * i / key_count
ts << t
ks << curvature_at_t(a, b, t)
end
# Integrate
dks = ks.dup
(1...dks.length).each do |i|
dks[i] += dks[i - 1]
end
max = dks.max
dks.map! { |dk| dk / max }
# Draw points
point_count = 36
(0...point_count).each do |v|
kn = v / pint_count.to_f
Sketchup.active_model.entities.add_cpoint(point_at_dk(a, b, ts, dks, kn))
end
La meilleure façon d'avoir les extremums et une répartition homogène est surement d'appliquer ta proposition seulement sur 1/4 d'ellipse et de dupliquer les positions trouvées sur les 3 autres.
Voici un bout de code qui peut être copier coller dans la console de SketchUp.
Il permet de dessiner les points répartis suivant la courbure sur un quart d'ellipse en fonction des paramètres qu'on lui donne au début.
Je pense qu'ensuite on pourrait utiliser la méthode des 3 points proposée par Kentaro pour former les arc en calculant un point milieu à chaque arc.
def point_at_t(xradius, yradius, t)
Geom::Point3d.new(xradius * Math.cos(t), yradius * Math.sin(t))
end
def point_at_dk(xradius, yradius, ts, dks, dk)
point_at_t(xradius, yradius, ts[dks.find_index { |v| v >= dk }])
end
def curvature_at_t(xradius, yradius, t)
(xradius * yradius) / Math.sqrt((xradius**2 * Math.sin(t)**2 + yradius**2 * Math.cos(t)**2)**3)
end
xradius = 5.0
yradius = 3.0
key_count = 100
arc_count = 8
prompts = [ "xradius", "yradius", "key_count", "arc_count" ]
defaults = [ xradius, yradius, key_count, arc_count ]
xradius, yradius, key_count, arc_count = UI.inputbox(prompts, defaults, "Settings")
ts = []
ks = []
ps = []
# Compute curvature at key points
(0..key_count).each do |i|
t = Math::PI / 2 * i / key_count
ts << t
ks << curvature_at_t(xradius, yradius, t)
end
# Integrate
dks = ks.dup
(1...dks.length).each { |i| dks[i] += dks[i - 1] }
max = dks.max
dks.map! { |dk| dk / max }
# Clear model
Sketchup.active_model.entities.clear!
# Draw points
(0..arc_count).each do |v|
p = point_at_dk(xradius, yradius, ts, dks, v / arc_count.to_f)
ps << p
Sketchup.active_model.entities.add_cpoint(p)
end
SKETCHUP_CONSOLE.clear
puts "-----"
puts "xradius = #{xradius}"
puts "yradius = #{yradius}"
puts "key_count = #{key_count}"
puts "arc_count = #{arc_count}"
puts "-----"
i = 1
ps.each_cons(2) do |p1, p2|
puts "arc #{i} => start = (#{p1.x.to_f.round(1)}, #{p1.y.to_f.round(1)}) end = (#{p2.x.to_f.round(1)}, #{p2.y.to_f.round(1)})"
i += 1
end
David Marmilloud j'ai peut-être mal compris la base du raisonnement, mais comment ces deux premiers rayons peuvent-ils être égaux si les deux extrémités de l'arc sont sur l'ellipse ?
David Marmilloud mais la il est question d’export 2D. Si des surfacés doivent être exploitées il y au ra l’export 3D.
J'ai poussé l'essai commencé ici pour que ça recherche les arc de cercles avec le point central de la portion et la méthode à 3 points.
Il en sort ceci. On voit que lorsque l'ellipse s'aplatit, on s'éloigne de plus en plus du fait que les portions d'arc de cercle soient tangentes les unes aux autres.
Et des NaN apparaissent dans la recherche des centres d'arc parce que les 3 points sont quasiment alignés ...
Je ne comprends pas tout à la représentation graphique
Ce qui se dessine c'est les points début et fin de chaque arc et un trait pointillé qui les relie au centre de chaque arc.
J'ai voulu reproduire ce que David Marmilloud montre dans son dessin avec les rayons coïncidents.
d'où les NaN
Les NaN sont surtout au début (t = 0) où les arcs sont très courts et donc les points début, milieu et fin des arcs trop proche pour ne pas être vu comme alignés dans la précision possible.
Oui dans ce cas nul autre choix que de remplacer par un segment ou de retirer le point étape.
le centre du cercle approchant part à l'infini
Oui, il y aura aussi ce cas à l'autre bout.
Je sais même pas si c'est vraiment une question de simplicité, mais plus d'objectif.
En effet, j'ai l'impression que si toutes les portions d'arc de cercle sont tangentes 2 à deux, on s'éloigne plus de la forme de l'ellipse que si on ne l'est pas.
Le choix est donc : forme ou continuité. Et en même temps avec plus de points, ça répond forcément mieux aux critères ... mais s'éloigne d'une "simplicité" pour l'exploitation du résultat.
Et je rejoins Kentaro que de base SketchUp est merdique sur cette notion de continuité. C'est donc de toutes façons pas pire que la donnée source.
Jean-Claude Di Fazio les arcs de cercles, même s'ils ne sont pas parfaitement tangents les uns aux autres offrent une bien meilleure continuité que la suite de segments. Même imparfait, c'est forcément une courbe plus douce et c'est ça qui est désiré.
Si on veut des segments, il n'y a rien à calculer, parce que ici c'est la donnée source qui est comme ça dans SketchUp.
Jean-Claude Di Fazio Ce type de construction ne peut donner qu’un cercle ou une spirale.
Je suis pas d'accord avec ça. L'approximation en 3 cercles montre le contraire.
Il est certain que ce n'est forcément pas un ellipse, puisque c'est une approximation
Merci mais sans tous les chouettes contributeur-ice—s, ce site ne serait pas ce qu’il est
Merci o314.
Il semble y avoir des choses à creuser, mais c'est le genre de lecture que j'ai du mal à comprendre :(.
pas reussi a indenter les listes. dsl
Il faut changer de puce -, puis +
Merci