Je programmment divers outils de simulation en C # /. NET
Ce que je recherche est une bibliothèque de visualisation de haut niveau; Créez une scène, avec une caméra avec des contrôles standard et rendez-vous quelques mille sphères Hunderd Mille Sphères, ou des images métalliques. Ce genre de chose. S'il faut plus d'une ligne pour initialiser un contexte, il s'écarte de mon idéal.
ive regardé Slimdx, mais son niveau inférieur que je cherche (au moins les pièces documentées, mais je ne m'occupe pas vraiment d'autre). La perspective WPF avait l'air cool, mais cela semble cibler les scènes définies statiques XAML, et cela ne me convient pas non plus non plus.
Fondamentalement, je cherche le type de fonctionnalités des langues comme BlitzBasic utilisé pour fournir. Cela existe-t-il du tout?
4 Réponses :
Peut-être le Xna Game Studio est ce que vous recherchez.
Jetez également un coup d'œil à DirectX .
Aucun de ceux-ci n'est de haut niveau dans le sens où l'OP demande. Il faut beaucoup de travail pour rendre même une sphère à Xna.
perspective WPF avait l'air cool, mais il semble cibler des scènes définies statiques xaml
Regardez à nouveau, WPF peut être aussi dynamique que vous aurez besoin.
Vous pouvez écrire n'importe quel programme WPF, y compris 3D, totalement sans XAML.
Merci; Je viens de comprendre ça aussi. Il a l'air bien à cet égard, mais pas si bien en ce que je vois beaucoup de rapports de cartes graphiques haut de gamme à genoux par une poignée de triangles. Je ne cherche pas de graphiques de haut niveau lisse soyeux. Juste une couche mince rapide et sale sur DirectX.
Je veux dire; Pas de haut niveau dans le sens de GDI + et WPF3D, comme dans la fourniture de tonnes de paramètres pour l'arrondissement des bords et toutes sortes de types d'œillet. Juste quelque chose de simple à garder un œil sur les concerts des données évoluant dans ma mémoire.
Je n'appellerais pas GDI + haut niveau, pas à côté du WPF.
Je suis également intéressé par cela (comme je développe également des outils de simulation) et avons fini par pirater ensemble des trucs de Xna. C'est certainement beaucoup plus de travail que ce que vous avez décrit. Notez que tout ce que vous pouvez faire dans WPF via XAML peut également être effectué via le code, car XAML est simplement une représentation d'une hiérarchie d'objets et de ses relations. Je pense que cela peut être votre meilleur pari, même si je n'ai aucune mesure sur quel type de performance à laquelle vous pourriez vous attendre avec quelques centaines de mille sphères (vous allez absolument avoir besoin d'abattage dans ce cas et que l'abattage lui-même peut être coûteux si vous n'utilisez pas d'optimisations telles que la partition de la grille.)
Edit: Si vous avez vraiment besoin de prendre en charge des entités de 100 000 000 000 et que vous pouvez tous être rendus comme des sphères, je vous recommanderais de contourner entièrement le moteur 3D entièrement et utilisez uniquement XNA pour les mathématiques. J'imagine une approche comme ce qui suit:
Utilisez XNA pour configurer la caméra (vue) et les matrices de perspective. Il a des fonctions statiques de matrice pratiques qui facilitent cela.
calculez la matrice de projection et projetez toutes vos points d'origine "sphère" à la visualisation de Frustrum. Cela vous donnera des coordonnées x, y et de la profondeur z dans le frustrum. Vous pouvez soit exprimer ceci sous forme de multiplications de matrice individuelles de 100k individuelles ou de multiplication de la matrice de projection par une seule matrice d'élément de 3 x 100k. Dans le premier cas, il s'agit d'un grand candidat au parallélisme utilisant la nouvelle fonctionnalité parallèle .NET 4.
Si vous constatez que les multiplications de matrice 100K sont un problème, vous pouvez réduire considérablement cela en effectuant un énorme des points avant la transformation si vous savez que seul un petit sous-ensemble d'entre eux sera visible à un moment donné. Par exemple, vous pouvez inverser la matrice de projection pour trouver les limites de votre frustrum dans votre espace d'origine et créer une boîte à bornisation alignée sur l'axe pour le frustrum. Vous pouvez ensuite exclure tous les points à l'extérieur de cette boîte (tests de comparaison simples en X, Y et Z.), il vous suffit de recomputer cette boîte de sélection lorsque la matrice de projection change, donc si elle change rarement, cela peut être une optimisation raisonnable.
Une fois que vous avez vos points transformés, clipez n'importe quel extérieur du tronc (z <0, z> maxdiste, x <0, y <0, x> largeur, y> hauteur). Vous pouvez maintenant rendre chaque point en tirant un cercle rempli, avec son rayon proportionnel à Z (Z = 0 aurait le plus grand rayon et z = maxdiste ne s'effondrerait probablement pas à un seul point.) Si vous voulez fournir un sentiment d'ombrage / de profondeur , vous pouvez rendre avec une brosse ombragée pour imiter très vaguement l'éclairage sur les sphères. Cela fonctionne parce que tout dans votre scène est une sphère et vous n'êtes probablement pas inquiet pour des choses comme des ombres. Tout cela serait assez facile à faire dans WPF (y compris la brosse ombrée), mais assurez-vous d'utiliser DrawingVisual classes et non-éléments-cadre. En outre, vous devrez vous assurer de dessiner dans la commande Z correcte. Il vous aide donc si vous stockez les points transformés dans une structure de données qui trie comme vous ajoutez.
Si vous rencontrez toujours des problèmes de performance, il y a d'autres optimisations que vous pouvez poursuivre. Par exemple, si vous savez que seul un sous-ensemble de vos points bouge, vous pouvez mettre en cache les emplacements transformés pour les points immobiles. Cela dépend vraiment de la nature de votre ensemble de données et de la manière dont elle évolue.
Étant donné que votre ensemble de données est si important, vous pourriez envisager de changer votre façon de le visualiser. Au lieu de rendre 100k points, partitionnez votre espace de travail dans une grille volumétrique et enregistrez le nombre (densité) des points à l'intérieur de chaque cube de grille. Vous ne pouvez projeter que le centre de la grille et le rendre comme une «sphère» avec des commentaires supplémentaires (comme la couleur, l'opacité ou la texture de la brosse) pour indiquer la densité de points. Vous pouvez combiner cette technique avec l'approche de rendu traditionnelle, en rendant les points proches des «sphères» et des points extrêmes tels que des objets «cluster» avec une brosse à mobilier pour correspondre à la densité. Un algorithme simple est de considérer une sphère de liaison autour de la caméra; Tous les points à l'intérieur de la sphère seront transformés normalement; Au-delà de la sphère, vous ne ferez que l'utilisation de la grille de densité.
Voir au dessus; Je viens de vraiment comprendre que vous "pouvez" faire cela dans le document WPF, mais la performance semble être une préoccupation. Cela dit, les sphères 100k faisant SPH ne vont pas mettre à jour très bien en douceur. Mais ce n'est pas acceptable pour un appel de rendu rapide et sale pour ajouter de manière significative à mon temps de simulation total. J'avais l'habitude de pirater ce genre de choses ensemble à OpenGL des années, mais j'avais espéré que c'était une chose du passé. Toute chance que vous soyez prêt à partager votre piratage? Je serais beaucoup obligé.
J'effectue mon rendu asynchrone à la simulation réelle. Cela a l'effet secondaire que les scènes rendues peuvent paraître «synchronisées» lorsque beaucoup de choses se déplacent ou si je suis simulée plus rapidement que la durée réelle (par exemple, un objet sera à la traîne derrière l'effecteur de fin qui le porte), mais la simulation dans physx reste précis. Je vais devoir vérifier ce que je suis libre de partager, étant donné des préoccupations de propriété intellectuelle avec ma société. Je ne suis pas particulièrement content de ma solution XNA actuelle en aucun cas (difficile à obtenir des choses simples simples comme l'éclairage de base) et peut expérimenter avec la fenêtre de la WPF.
Merci pour l'entrée Dan; ive écrit mes propres rasterizers et Raytracers, alors je pouvais le faire à nouveau, mais ce n'est pas ce que je suis payé pour le moment. Ce que je veux, la performance sage est un seul tampon de coordonnées dans le GPU RAM étant rendu, que je mettez à jour à ma propre loisir. Si vous manipulez des matrices moi-même sur la CPU, cela s'écarte de ce que je veux à la fois en termes de niveau d'abstraction et de performances.
Devez-vous utiliser c # /. net ou monoduelop sera-t-il suffisant? Je peux recommander http://unity3d.com/ si vous voulez un puissant moteur 3D.
Hmm, a l'air intéressant, mais cela signifie-t-il que je dois quitter Visual Studio?
Vous allez toujours programmer dans Visual Studio et utiliser C # mais je ne suis pas totalement sûr de quelle version de .NET monodevelop utilisé par Unity supporte actuellement. Mais vous obtenez le bonus supplémentaire que votre produit devient multiplate-forme :)
Trouvé ce forum-link: forum.unity3d.com/threads/...
Mise à jour: Je viens de remarquer une enveloppe OpenSource .NET pour VTK a été publiée, appelée Activiz. Cela a l'air un peu bon, mais je ne suis pas convaincu à 100%. Je cherche quelque chose de beaucoup plus léger.