Indeck est une application d'environnement de codage 3D autonome pour développer la VR à partir de la VR. Le projet est écrit en Lua et se déroule sur le cadre de Lövr. Lövr et Indeck peuvent cibler toutes les plates-formes VR couramment accessibles.

Le principal avantage de l'environnement Indeck est une boucle d'itération serrée entre le code LUA et l'exécution 3D interprétée. Lorsque le code est instantanément synchronisé avec l'exécution de l'exécution, le développement devient plus engageant et productif. Ne pas avoir à décoller constamment et à mettre sur le casque VR élimine également un peu de frottement.
La plate-forme de mise au point est Oculus Quest avec le clavier Bluetooth connecté. Bien que la quête soit considérée comme une plate-forme de consommation et une cible pour le développement de bureau, Indeck le transforme en une unité de développement VR autonome. Indeck fonctionne dans tout autre environnement qui peut exécuter Lövr et a le clavier attaché.
Au stade actuel, Indeck est fonctionnel et utile, mais pas terriblement convivial. Je l'utilise régulièrement pour le prototypage VR et les ajustements de projets existants. Le projet est d'être un environnement de développement simple et extensible, et non un IDE poli en fonctionnalité avec une API stable.
Indeck se compose d'un éditeur de code LUA rendu en 3D et du harnais pour l'exécution du projet utilisateur. Plusieurs instances d'éditeur peuvent être ouvertes et librement positionnées dans l'espace. Un seul éditeur est ouvert au début et peut être utilisé pour charger et exécuter tout projet Lövr. Lorsque le projet sera exécuté, il commencera à s'exécuter et le fichier source principal sera ouvert dans l'éditeur de code. Au fur et à mesure que l'utilisateur modifie le code du projet, il peut parfois recharger l'exécution pour réexécuter le code modifié. Le rechargement partiel et le redémarrage complet de l'environnement sont pris en charge. Si l'utilisateur introduit une erreur dans son code, l'exécution du projet sera interrompue et l'utilisateur a la possibilité de corriger rapidement l'erreur à l'aide d'une trace de pile et de redémarrer l'exécution.
Par conception, l'environnement Indeck ne peut accéder qu'à des fichiers dans le répertoire "Enregistrer" de Lovr. Tout projet Lövr existant devrait fonctionner prêt à l'emploi à l'intérieur de l'environnement Indeck une fois qu'il est copié à l'emplacement correct:
/sdcard/Android/data/org.indeck.app/files/projects/Users/<user>/Library/Application Support/LOVR/indeck/projects/home/<user>/.local/share/LOVR/indeck/projectsC:Users<user>AppDataRoamingLOVRindeckprojects L'éditeur de code est une implémentation assez standard (si minimale) de l'éditeur de texte avec la syntaxe LUA mettant en évidence, principalement modélisée après le texte sublime. L'éditeur est entièrement entraîné par des raccourcis clavier sans aucune boîte de dialogue, popups ou modaux. Les interactions de la souris et du contrôleur VR sont complètement absentes pour éviter les affrontements avec la manipulation du contrôle dans les projets d'utilisateurs.
Remarque: L'éditeur ne demande jamais à enregistrer les modifications sur la fermeture et toute progression non enregistrée est perdue
L'utilisateur peut exécuter une seule ligne de code LUA sous le curseur en appuyant sur le Ctrl + Shift + Entrée . Le code est exécuté dans le contexte de l'éditeur actuellement actif. Le résultat d'exécution apparaît dans la ligne d'état en haut de l'éditeur. Par exemple, la saisie return 2 + 2 dans l'éditeur et l'exécution de cette ligne mettra "OK> 4" dans la ligne d'état, indiquant l'état de l'exécution et le résultat.
Ce mécanisme d'exécution de la ligne de code est utilisé comme moyen direct d'interagir avec l'environnement de développement. La navigation sur la structure des fichiers et le choix d'un projet à exécuter se font en sélectionnant une ligne avec la commande préparée et en l'exécutant avec Ctrl + Shift + Entrée . Ces commandes sont automatiquement construites en fonction des listes de répertoires.
Raccourcis:
Ctrl+Shift+Enter Exécute la ligne éditée en tant que morceau LUA à une seule ligneCtrl+Shift+Home Place l'éditeur devant l'orientation actuelle de la têteCtrl+P crée un nouvel éditeurCtrl+W ferme l'éditeur actuel (même avec des changements non sauvés!)Ctrl+Tab sélectionne l'éditeur suivantCtrl+O répertorie les fichiers pour l'ouverture dans l'éditeur actuel (élimine les modifications non sauvées!)Ctrl+S enregistre les modifications du fichier ouvertCtrl+H ouvre la documentation de l'API LOVR dans un éditeur séparéCtrl+Shift+S Store éditeurs actuels dans un fichier de sessionCtrl+Shift+L Ouvre les éditeurs chargés à partir d'un fichier de sessionCtrl+Shift+P exécute le profileur de code pendant une durée d'une seconde et affiche le rapport dans l'éditeur séparéCtrl+down saute 10 lignes vers le basCtrl+up saute 10 lignes Lorsque le projet utilisateur est chargé, ses fonctions de rappel (dessiner, mise à jour ...) seront exécutées comme elles le feront si le projet était exécuté en mode autonome.
La modification du code et l'exécution du projet utilisateur peuvent entraîner une erreur d'exécution. L'environnement d'interprétation cessera ensuite d'exécuter le projet, tandis que tous les éditeurs ouverts continueront de fonctionner. Un nouveau volet d'éditeur apparaîtra contenant la trace de pile au point d'erreur. Lorsque l'erreur est traitée avec Utilisez le CTRL + R pour exécuter le projet utilisateur dès le début.
Avant d'exécuter le projet, son répertoire est monté en / root. Cela permet au code utilisateur de continuer à utiliser des chemins relatifs lors du chargement des actifs, comme il le ferait normalement lors du développement en dehors de l'environnement Indeck. Par exemple, si Bark.ogg existe dans le répertoire du projet utilisateur, le lovr.data.newSound('bark.ogg') peut être utilisé pour le charger.
Veuillez signaler toute divergence entre l'exécution du projet Lövr indépendamment et dans l'environnement Indeck.
Il existe deux méthodes de mise à jour d'un environnement en cours d'exécution avec du code modifié. La méthode de base est un redémarrage complet de l'application. Tous les modifications de code sur tous les fichiers seront rechargées. L'inconvénient principal est que tout le contexte de l'éditeur est perdu (fichiers ouverts, positions de défilement, modifications), alors assurez-vous d'enregistrer manuellement la session de l'éditeur avant de redémarrer. Le redémarrage peut également être lent si le projet utilisateur a beaucoup de code d'initialisation (chargement ou génération d'actifs).
L'autre méthode de rechargement est l'échange à chaud partiel, qui oblige le fichier de code source main.lua du projet utilisateur à réexécuter. Seul le projet utilisateur est rechargé, donc le contexte de l'éditeur est préservé. Cela permet des cycles d'itération rapides et efficaces s'ils sont utilisés correctement. La méthode de swap à chaud peut être très efficace lors de la conception de la logique de l'application, de la modification du code du shader ou de la peaufinage des constantes.
Il y a des règles sur les parties de l'exécution qui seront affectées lors du hotwaping. Ce ne sont que les mécanismes LUA standard pour le chargement des modules; Il n'y a pas de «magie» supplémentaire au travail. Ils sont toujours une source d'erreurs commune et importantes à comprendre. L'indeck en soi ne réexécutera le fichier source main.lua que en forçant l'exécution à oublier la version précédemment chargée: package.loaded['main'] = nil . Si un autre module était déjà require «D de main.lua lors de l'exécution précédente, il ne sera plus traité et la version déjà chargée sera réutilisée. Pour forcer le sous-module à être rechargé dynamiquement sur un swap chaud, insérez le package.loaded['module_name'] = nil line dans le fichier main.lua avant sa commande require(module_name) . Cela permet un contrôle à grains fins sur les parties du projet utilisateur à réexécuter pendant le swap chaud, et les parties des données / l'état d'application peuvent être conservées à travers l'échange chaud.
Lorsque l'éditeur répertorie les fichiers dans le répertoire racine, il présentera également des options pour basculer entre différents projets d'utilisateurs. Cela exécutera le nouveau projet dans le même environnement; Cela fonctionne souvent bien, mais peut causer des problèmes subtils si les projets chargés changent l'état mondial. Il est recommandé de redémarrer l'application avant de changer de projets pour s'assurer que l'environnement est propre.
Raccourcis:
Ctrl+Shift+R redémarre l'applicationCtrl+R Recharges (échange chaud) Le main.lua du module utilisateurEsc sort dans le système d'exploitation Alors que Lövr prend en charge l'exécution du projet à partir de tout nom de fichier, Indeck ne prend en charge que l'exécution des répertoires avec le fichier main.lua à l'intérieur. Les projets d'utilisateurs ne doivent pas contenir de fichiers ou de dossiers nommés projects . Une telle entité s'affronterait avec le répertoire "Projets" une fois que le répertoire du projet utilisateur sera monté sur la racine du répertoire de sauvegarde. L' indeck-session.lua est un autre nom de fichier réservé utilisé en interne.
Le fichier conf.lua du projet utilisateur ne sera pas traité. Indeck essaie de fournir sa propre configuration polyvalente, qui devrait couvrir les besoins de différents projets. Si votre projet a des problèmes lors de l'exécution dans Indeck, veuillez ouvrir un problème.
L'éditeur de code n'a pas quelques fonctionnalités de base, comme la fonction de recherche et la commande UNDO.
Une connaissance pratique du cadre Lövr est nécessaire afin de développer efficacement des applications complètes, sans enlever le casque constamment pour rechercher la documentation. Bien qu'il ne soit pas aussi lisible que la documentation officielle, l'environnement Indeck comprend tous les fichiers API Lövr qui répertorient les fonctions et les explications des paramètres. Les documents API sont accessibles en appuyant sur la touche Ctrl+H
Pour démarrer l'application Indeck sur Quest à distance à partir du PC, exécutez la commande adb shell am start org.indeck.app/org.indeck.app.Activity Commande. La même ligne peut être ajustée pour fonctionner dans le Shell Termux sur quête (Termux peut également exécuter Git sur Quest).