whitedune - online na nuvem

PROGRAMA:

NOME

whitedune - editor gráfico vrml97 e ferramenta de animação

SINOPSE

Whitedune [ variantes ] [ opções estereoscópicas ] [ opções de dispositivo de entrada [ Axoptions ] [
opções erradas ] [ arquivo.wrl arquivo.x3dv arquivo.xml ... ]

Whitedune [ opção de conversão ] nome do arquivo

Whitedune -ilegal2vrml [ -prefixo prefixo ] protofile.wrl arquivo.wrl ...

DESCRIÇÃO

Whitedune / white_whitedune é um editor gráfico para modelagem de realidade virtual
Language (VRML97), ISO / IEC 14772-1: 1997.
Além disso, tem suporte para o NurbsSurface Node descrito na Alteração 97 de VRML1.
white_whitedune também pode carregar e armazenar arquivos X3DV codificados por VRML
Ele também pode carregar arquivos X3D com codificação XML, se configurado para usar uma linha de comando
tradutor vrml97 / x3d.
Um nome de arquivo de - significa entrada padrão.
Dune tem algum suporte básico para visão estereográfica, geralmente com vidros do obturador em OpenGL
modo "quadbuffer".
Quando usado com as opções de conversão ou o -ilegal2vrml argumento de linha de comando,
white_whitedune é um programa de linha de comando não gráfico.
As opções de conversão são usadas para converter o arquivo VRML / X3DV em código fonte ou outro 3D
formato gráfico. Estas opções são usadas na linha de comando, mas algumas opções requerem um
contexto gráfico (por exemplo, no caso mais simples, um uso dentro de um xterm comando), causa alguns dos
as opções de conversão requerem o uso de comandos OpenGL. Para criar um contexto OpenGL,
existem 3 maneiras diferentes.
Primeiro abra uma janela gráfica temporária, faça a conversão e feche a janela gráfica e
saída. Isso é usado atualmente em M $ Windows.
A segunda é usar a renderização fora da tela do Mesa (o programa foi compilado com o --with-
opção de configuração osmesa). Com Mesa fora da renderização da tela é possível usar OpenGL
comandos em um programa de linha de comando puro.
O terceiro é usar a renderização fora da tela baseada em glx no Linux / UNIX / MacOSX. Neste caso, não
o programa não abre uma janela gráfica, mas requer um monitor X11 funcional de qualquer maneira. Com um
console de texto o XvfbGenericName O programa do servidor X11 pode ser usado para obter um display X11 funcional.
A -ilegal2vrml opção é usada para reparar arquivos VRML97 com extensões ilegais.
veja a ilegal2vrml(1) página de manual para mais informações.

OPÇÕES DE VARIANTES

-4 crianças comece o whitedune com uma GUI simplificada como um modelo 3D simples para crianças.

-x3dv se nenhum arquivo for carregado, comece whitedune com um novo arquivo X3DV.
Por padrão, whitedune é iniciado com um novo arquivo VRML97.

-kambi comece whitedune com suporte para nós de extensão não portáveis, utilizáveis ​​apenas com o
gameengine kambi VRML.

-cobrir comece whitedune com suporte para nós de extensão não portáveis, utilizáveis ​​apenas com o
capa / covise do visualizador VRML97 imersivo especial.

-4catt comece whitedune com uma GUI simplificada como um exportador / conversor para usuários do CATT
8 software de simulação de som.

-bw Use ícones preto e branco em vez de ícones coloridos

-alemão
Use o menu alemão, diálogos e mensagens de erro

-italiano
Use o menu e as caixas de diálogo em italiano, as mensagens de erro ainda estão em inglês

-Inglês
Use o menu em inglês, diálogos e mensagens de erro. Este é o padrão que pode ser usado para
sobrescrever a configuração da variável de ambiente LANG.

OPÇÕES DE CONVERSÃO

-vrml97
Converta o arquivo para VRML97 ISO / IEC 14772-1: 1997, grave-o na saída padrão e saia.

-vrml97levelx3dv
Converter arquivo para VRML97 ISO / IEC 14772-1: 1997 partes compatíveis do X3D clássico VRML
codificação ISO / IEC ISO / IEC 19776-2: 2005, grave-o na saída padrão e saia.

-x3d Converta o arquivo em X3D codificado em XML, grave-o na saída padrão e saia.

-kanim padrão de nome de arquivo
Converta o arquivo no formato de arquivo kanim e grave-o na saída padrão.
O formato de arquivo kanim é um arquivo XML com referências a diferentes arquivos VRML. o
Os arquivos VRML também são gerados, seus nomes são gerados com base em padrão de nome de arquivo: O
filenamepattern é um encurtamento da extensão do arquivo e, em seguida, estendido com um
sublinhado, um número crescente e a extensão .wrl.
Todos os arquivos VRML descrevem a mesma cena VRML com os mesmos nós, mas alguns numéricos
os campos são animados.
Este tipo de arquivo é usado pelo mecanismo de jogo Kambi baseado em VRML de código aberto. Faz
não faz sentido exportar um arquivo kanim, se o arquivo VRML exportado não contém
animação baseada em sensor de tempo / interpolador.

-país das maravilhas diretório do módulo
Converter o arquivo em um arquivo fonte java incluído em uma estrutura de diretório necessária para
construir um módulo SUN Wonderland versão 0.5 e sair.
Se o diretório raiz do módulo for construído a partir da entrada nome do arquivo (sem
extensão) como diretório do módulo/ exportX3dv /nome do arquivo
Se este diretório e os outros arquivos necessários não existirem, estes arquivos também são
criada. Se os outros arquivos existirem, eles não serão substituídos, apenas o java de destino
a própria fonte é substituída. O nome do arquivo de origem java de destino é
diretório do módulo/ exportX3dv /nome do arquivo/ src / classes / org / jdesktop / wonderland / modules /nome do arquivo/ client / jme / cellrenderer /nome do arquivo.Java
O primeiro caractere do arquivo de origem java de destino é maiúsculo.
Para obter um módulo do país das maravilhas do diretório do módulo/ exportX3dv /nome do arquivo diretório,
chance para este diretório e execute o formiga comando. Um arquivo jar usual do
módulo do país das maravilhas pode então ser encontrado no diretório do módulo/ exportX3dv /nome do arquivo/ dist
diretório.
Ao compilar a saída da exportação do código-fonte Java do país das maravilhas com o comando
formiga, o compilador java pode ficar sem recursos de memória.
Para resolver o problema, você pode definir os limites de memória estendendo a tag javac no
arquivo wonderland / build-tools / build-scripts / build-setup.xml, por exemplo
<javac...
...
fork = "verdadeiro"
memoryinitialsize = "256m"
memorymaximumsize = "1024m"
>
Actualmente, o -país das maravilhas opção suporta apenas saída de modelador 3D estático sem
animação ou interação.
Esses recursos estão em andamento e ainda precisam ser concluídos.
Esta opção usa comandos OpenGL.

-x3d4país das maravilhas
Converta o arquivo para XML codificado em X3D para importação no SUN Wonderland 0.4, escreva para
saída e saída padrão.
SUN wonderland 0.4 suporta apenas IndexedFaceSets com colorPerVertex e fullsize
Nós de cor. Este exportador tenta converter outros nós para este IndexedFaceSets,
mas pode (atualmente) não converter corretamente os nós com colorPerVertex false e
Nós de cores em tamanho real.
Esta opção usa comandos OpenGL.

-ac3d Converta o arquivo para o formato AC3D (versão AC3Db), grave-o na saída padrão e
saída. Esta opção usa comandos OpenGL.
O formato de arquivo AC3D é o formato de arquivo de entrada / saída do modelador 3D ac3d.
O modelador ac3d 3d não suporta vários recursos de VRML / X3D (por exemplo, o ac3d 3d
modelador não suporta animação ou interação). Portanto, o formato de arquivo AC3D
não pode manter as informações completas de um arquivo VRML / X3D em geral.

-catt8geo outputdir_with_material_geo
Converta o arquivo para o formato catt geo (versão 8), grave-o em vários formatos .geo
para o diretório outputdir_with_material_geo e sair.
O formato de arquivo catt geo é o formato de arquivo de geometria de entrada do catt acústico
programa de simulação.
O arquivo master.geo neste diretório outputdir_with_material_geo irá segurar incluir
comandos para os outros arquivos .geo produzidos.
No diretório, deve existir um arquivo material.geo com os comandos ABS necessários
antes da conversão. Os nomes dos materiais para os nomes ABS são gerados a partir do DEF
nomes dos nós VRML.
Se o arquivo material.geo não existir no outputdir_with_material_geo diretório,
white_whitedune falha com uma mensagem de erro.
Apesar do programa catt poder exportar arquivos VRML97, ele não suporta vários
recursos de VRML / X3D.
Portanto, o formato de arquivo catt geo não pode manter as informações de um arquivo VRML / X3D
em geral.
Esta opção usa comandos OpenGL.

-ldraw Converta o arquivo para a maior parte do formato de arquivo ldraw e grave-o no padrão
saída.
O cabeçalho do arquivo ldraw não é gerado. O cabeçalho é uma parte importante de um
ldraw arquivo e deveria ter sido escrito para a saída padrão antes (normalmente este
é feito a partir de um script em lote).
O formato de arquivo ldraw é um formato de arquivo ASCII que é usado para trocar dados 3D
entre vários programas de descrição de tijolos de plástico de código aberto. Um exemplo para tal
um programa é LeoCAD.

-prefixo prefixo
A -prefixo opção em conjunto com a conversão é usada apenas para o seguinte
opções para criar o código-fonte. Pode ser usado para definir um prefixo principal para o
nome das estruturas de dados na saída do código-fonte.
Por exemplo, o código-fonte cria tipos de dados chamados "Node", "Scenegraph" e
"Ligar de volta". Para evitar problemas com outras bibliotecas, adicionando opções como por exemplo
"-prefixo X3d "mudaria os nomes para" X3dNode "," X3dSceneGraph "e
"X3dCallback".

-c Converte o arquivo em um arquivo de cabeçalho / fonte C, grava-o na saída padrão e sai.
Atualmente, as informações sobre as rotas não são exportadas.
Veja a seção C / C ++ / JAVA FONTE EXPORTAR para obter mais informações.

+c prefixo
Esta opção é muito semelhante ao -c opção, mas grava um arquivo de origem incompleto,
que pode ser concatinado a um arquivo de origem escrito pelo -c opção.
Os nomes dos novos tipos de dados definidos no arquivo de origem começam com o prefixo
argumento.

-3c Esta opção é semelhante ao -c opção, mas as superfícies são primeiro trianguladas e
em seguida, exportados como nós TriangleSet.
Esta opção usa comandos OpenGL.

+ 3c prefixo
Esta opção é muito semelhante ao -3c opção, mas grava um arquivo de origem incompleto,
que pode ser concatinado a um arquivo de origem escrito pelo -3c opção.
Os nomes dos novos tipos de dados definidos no arquivo de origem começam com o prefixo
argumento.

-malha Esta opção é semelhante ao -c opção, mas as superfícies são primeiro convertidas em um
malha de polígono e depois exportada como nós IndexedFaceSet.

+ meshc prefixo
Esta opção é muito semelhante ao -malha opção, mas grava uma fonte incompleta
arquivo, que pode ser concatinado em um arquivo de origem escrito pelo -malha opção.
Os nomes dos novos tipos de dados definidos no arquivo de origem começam com o prefixo
argumento.

-c ++ Converte o arquivo em um arquivo de cabeçalho / fonte C ++, grava-o na saída padrão e sai.
Atualmente, as informações sobre as rotas não são exportadas.
Veja a seção C / C ++ / JAVA FONTE EXPORTAR para obter mais informações.

+ c ++ prefixo
Esta opção é muito semelhante ao -c ++ opção, mas grava uma fonte incompleta
arquivo, que pode ser concatinado em um arquivo de origem escrito pelo -c ++ opção.
Os nomes dos novos tipos de dados definidos no arquivo de origem começam com o prefixo
argumento.

-3c ++ Esta opção é semelhante ao -c ++ opção, mas as superfícies são primeiro trianguladas e
em seguida, exportados como nós TriangleSet.
Esta opção usa comandos OpenGL.

+ 3c ++ prefixo
Esta opção é muito semelhante ao -3c ++ opção, mas grava uma fonte incompleta
arquivo, que pode ser concatinado em um arquivo de origem escrito pelo -3c ++ opção.
Os nomes dos novos tipos de dados definidos no arquivo de origem começam com o prefixo
argumento.

-meshc ++
Esta opção é semelhante ao -c ++ opção, mas as superfícies são primeiro convertidas em um
malha de polígono e depois exportada como nós IndexedFaceSet.

+ meshc ++ prefixo
Esta opção é muito semelhante ao -meshc ++ opção, mas grava uma fonte incompleta
arquivo, que pode ser concatinado em um arquivo de origem escrito pelo -meshc ++ opção.
Os nomes dos novos tipos de dados definidos no arquivo de origem começam com o prefixo
argumento.

-Java Converte o arquivo em um arquivo fonte java, grava-o na saída padrão e sai.
Atualmente, as informações sobre as rotas não são exportadas.
Veja a seção C / C ++ / JAVA FONTE EXPORTAR para obter mais informações.

+ java prefixo
Esta opção é muito semelhante ao -Java opção, mas grava uma fonte incompleta
arquivo, que pode ser concatinado em um arquivo de origem escrito pelo -Java opção.
Os nomes dos novos tipos de dados definidos no arquivo de origem começam com o prefixo
argumento.

-3java Esta opção é semelhante ao -Java opção, mas as superfícies são primeiro trianguladas e
em seguida, exportados como nós TriangleSet.
Esta opção usa comandos OpenGL.

+ 3java prefixo
Esta opção é muito semelhante ao -3java opção, mas grava uma fonte incompleta
arquivo, que pode ser concatinado em um arquivo de origem escrito pelo -3java opção.
Os nomes dos novos tipos de dados definidos no arquivo de origem começam com o prefixo
argumento.

-meshjava
Esta opção é semelhante ao -Java opção, mas as superfícies são primeiro convertidas em um
malha de polígono e depois exportada como nós IndexedFaceSet.

+ meshjava prefixo
Esta opção é muito semelhante ao -meshjava opção, mas grava uma fonte incompleta
arquivo, que pode ser concatinado em um arquivo de origem escrito pelo -meshjava opção.
Os nomes dos novos tipos de dados definidos no arquivo de origem começam com o prefixo
argumento.

-muitas aulas
Válido somente após o -Java, -3java, -meshjava or -país das maravilhas opções.
Esta opção é uma tentativa de força bruta para lutar contra as "constantes demais"
problema em java. Pode ser impossível compilar a saída de um java normal baseado
exportação de código-fonte, porque o formato atual dos arquivos de classe java são limitados a 64K
as chamadas "constantes". Não apenas constantes reais como 1, 2 ou 3 são contadas, mas também
coisas como definições de variáveis ​​de membro em classes etc.
Com o -muitas aulas opção, todos os dados são distribuídos em muitas classes separadas.
A -muitas aulas opção deve ajudar, se você encontrar "constantes demais"
problema. No caso de um grande número de comandos DEF no arquivo vrml / x3dv, você pode
ainda corre o problema de "constantes demais", porque cada comando DEF leva a
variável de membro na classe principal do cenário gráfico. Neste caso, você deve reduzir o
número de comandos DEF com o ponto de menu ações ... resto of cenário ramo ...
remover ... DEF nome
Ao lado da necessidade de aumentar os limites de memória do Javac compilador (-Xms/-Xmx)
opções, você também pode precisar aumentar o PermSize limites de memória
(-XX: PermSize =/-XX: MaxPermSize =) Do Java intérprete.

OPÇÕES DE VISTA ESTÉREO

-nostereo
forçar modo sem visão estereoscópica no Linux / UNIX (por exemplo, se você não possui shutterglases)

-estéreo
forçar o modo de visão estereoscópica.
Estéreo só é compatível com combinações de hardware / software, que permitem quadbuffer
estéreo ("estéreo em uma janela"), NÃO estéreo de tela dividida (por exemplo, "OpenGlVR").
Exemplos de combinações de hardware / software com suporte para estéreo quadbuffer são
placas gráficas com suporte para óculos ou "cloneview estéreo" para conectar
beamers de um onewall.

-anaglifo tipo de vidro
forçar o modo de visão estereoscópica experimental para uso com óculos anáglifos coloridos.
tipo de vidro pode ser red_green, green_red, red_blue ou blue_red.
Esta opção usa o buffer de acumulação OpenGL. Isso não é suportado por hardware por
muitas placas de vídeo / drivers gráficos e pode resultar em desempenho péssimo.

-olho distinmetro ocular
Distância entre os dois olhos do observador.
Padrão distinmetro ocular é 0.06, pode ser negativo para trocar de olhos (não há necessidade de
reconfigure seu hardware se ocorrerem problemas de troca de olhos).

-screendist distinômetro de tela
Distância entre os olhos do espectador e o meio da tela do monitor.
Padrão distinômetro de tela é 0.8.

-campo de visão campo de visão em grau
Substituir o campo Field of View em pontos de vista VRML e definir como fieldofviewindegree em
grau.
Uma boa visão estereoscópica pode desejar ignorar o campo fieldOfView dos pontos de vista. o
fieldOfView do olho humano tem cerca de 18 graus, o VRML padrão é 45 graus.

OPÇÕES DE ENTRADA

As seguintes opções são válidas apenas se whitedune foi compilado com dispositivo de entrada correspondente
suporte de driver (por exemplo, não há suporte para um joystick Linux no IRIX).

-controle de video game dispositivo joystick
Válido apenas em Linux ou M $ Windows.
No Linux, dispositivo joystick é o dispositivo de um joystick Linux (geralmente algo
como / dev / input / js0 ou / dev / js0).
Sob M $ Windows, o dispositivo joystick é um número. Dependendo do M $ Windows
versão, este número é 0, 1 ou um número de 0 a 15.

-SDL joystick dispositivo joystick
Atualmente válido apenas em MacOSX. o dispositivo joystick é um número (por exemplo, 0, 1, 2,
...).

-bola espacial dispositivo de base espacial
dispositivo de base espacial é o dispositivo serial conectado à bola espacial (geralmente algo
como / dev / ttyd2 ou / dev / ttyS0).
Válido apenas se o binário foi compilado com suporte para libsball.

-nxtdials dispositivo USB
Esta opção suporta dials como dispositivo de entrada feito de motores Mindstorms nxt. Somente
anexe uma roda ou engrenagem a cada um dos 3 motores, conecte-os ao tijolo e conecte
o tijolo para o computador via USB.
Esta opção só é válida se white_whitedune foi compilado com suporte do
Biblioteca libusb, por exemplo, disponível no Linux.
dispositivo USB é o número do bloco nxt de tempestades mentais conectado via USB (0 para o
primeiro tijolo nxt, 1 para o segundo tijolo nxt, etc.).
A -nxtdials opção define automaticamente a opção do eixo da roda.

-xinput nomexinput
nomexinput é o nome do dispositivo compatível com o protocolo Xinput (geralmente algo
como Magellan ou Dialbox).
Válido na maioria das implementações Unix / X11.

-xinputlista
Imprima uma lista de nomes de dispositivos Xinput que podem ser usados ​​como nomexinput para o
-xinput opção e sair.
Válido na maioria das implementações Unix / X11.

-xinputlistlong
Imprima uma lista de nomes de dispositivos Xinput com informações de eixo e saia.
Válido na maioria das implementações Unix / X11.

-um rebanho dispositivo aflock [ opções de bloqueio ] -rastreador passarinho -varinha passarinho
dispositivo aflock é o dispositivo serial conectado ao mestre do Rebanho de Pássaros da Ascensão
transmissor (geralmente algo como / dev / ttyd2 ou / dev / ttyS0).
Dune assume a seguinte configuração:
Múltiplos FOBs com interface RS232 única para computador host (ver "O rebanho de
Aves, Guia de instalação e operação, autônomo e múltiplo
Configurações de transmissor / sensores múltiplos ", página 3 (capítulo" Introdução "),
Figura 2).
passarinho é o endereço da Unidade de Aves do rastreador de cabeça magnética (-rastreador) ou
"Mouse 3D" (-varinha) no Fast Bird Bus (endereço FBB) conforme configurado com o
interruptores na unidade Bird.
Este programa precisa ter o Bando de Pássaros configurado no Modo de Endereço Normal
apenas (consulte a página 12, Figura 4 do manual descrito acima).

-headnavigation
Use o modo de transformação atual (incluindo rotações) ao usar um headtracker.
O padrão sem -headnavigation está usando apenas o modo de tradução. Este padrão
dá a você uma reação muito natural, quando sua cabeça se move, o mundo virtual se move,
mas se sua cabeça apenas girar, o mundo virtual ficará parado. Com o
opção de navegação da cabeça, o mundo virtual reage às rotações da cabeça, dependendo do
modo de transformação atual. Tenha cuidado ao usar esse recurso ao falar com um
público. Falar causa pequenas e rápidas rotações da cabeça e causará pequenas e rápidas
rotações do mundo virtual. Seu público pode ter uma impressão como em um
terremoto e corre mais risco de enjoo.

-enviar sempre
Diga ao whitedune que o dispositivo envia (quase) sempre valores. Esses valores irão então
não ser interpretado automaticamente como comandos de transformação.
Usado automaticamente para o dispositivo Ascension Flock of Birds (-aflock).

-não se preocupe com o foco
As ações do dispositivo de entrada não se preocupam com o foco da janela.
Isso pode ser útil em situações em que você trabalha apenas com uma janela de música branca,
por exemplo, ao usar um onewall.

AXISOPÇÕES

-x | -y | -z | -xrot | -yrot | -zrot = [-] [número_de_axis inteiro]
[, [fator] [, [aceleração] [, [roda] [, ignorar]]]]

-all | -allxyz | -allrot = [fator] [, [acel] [, [roda] [, ignorar]]]

-nenhum = integer_axisnumber

-axes = max_number_axes

LEGENDA DO EIXO

- usado para trocar o sinal de valor do eixo

número_eixo_inteiro
Inteiro com o número do eixo, que deve ser usado para xyz xrot yrot
direções zrot.
Este número não pode ser maior que o número de eixos do dispositivo de entrada.
O integer_axisnumber na opção none é usado para desabilitar este eixo.

fator Flutua com um multiplicador para os eixos
Os fatores das opções all, allrot e allxyz são independentes dos fatores de
os eixos simples.

acel Flutuar com um acelerador potencial para os eixos

roda A string "roda" significa que este eixo do dispositivo de entrada não entregará zero se
liberado

ignorar Flutue com o valor (em relação ao valor máximo do dispositivo) que será
ignorado (insensibilidade)

max_number_axes
Número de eixos usados, um de (2,3,4,5).
Isso deve ser igual ou inferior aos eixos físicos disponíveis de um dispositivo. Uso principal
desta opção é desabilitar eixos mal projetados ou com defeito mecânico, por exemplo, quando você
desejo, este eixo em um joystick não existiria

OPÇÕES DE FLOCO

Estas opções são válidas apenas para o sistema de rastreamento magnético de bando de pássaros da Ascensão.

-baud taxa de transmissão
Taxa de transmissão da linha serial que se comunica com o transmissor.
De acordo com o manual do bando de pássaros, as seguintes taxas de transmissão são válidas para
comunicação de linha: 2400, 4800, 9600, 19200, 38400, 57600 e 115200.
Padrão: 38400

-numbirds pássaros numéricos
Número de pássaros "entregando dados" anexados ao transmissor (por exemplo, sem contar
o próprio transmissor, se for um controlador de alcance estendido (ERC)).
Padrão: 2 (rastreador e varinha).

-mestre passarinho
Endereço do transmissor mestre no Fast Bird Bus (endereço FBB) conforme configurado
com os interruptores na unidade transmissora.
Padrão: 1

-masterIsErc
Usado para diferir entre as configurações, onde o mestre é um ERC (Extended Range
Controlador) ou não. Se o mestre não for um ERC, o endereço FBB é o mesmo que o
Endereço FBB do rastreador ou da varinha.
Padrão: não definido

-hemisfério FRONT_HEM | AFT_HEM | UPPER_HEM | LOWER_HEM | LEFT_HEM | RIGHT_HEM
Hemisfério usado. Sente-se no bloco da antena (com as pernas próximas ao lado do
texto) para ver o que é esquerdo ou direito 8-)
Padrão: RIGHT_HEM

-sincronizar 0 | 1
Sincronize (1) ou não (0) a saída de dados para um CRT (Monitor) ou seu computador host.
A sincronização é usada para eliminar os efeitos magnéticos de um monitor usando o CRT
cabo de sincronização.
Padrão: 0

-quadra 0 | 1
Defina (1) ou não defina (0) a bandeira FNDELAY para o filedescriptor do serial
porta.
Padrão: 0

-filtro AC_NARROW | AC_WIDE | DC_FILTER
Habilite filtros diferentes. Leia os manuais do Bando de Pássaros para mais informações.
Esta opção pode ser repetida para usar vários filtros.
Padrão: nenhum filtro definido, usando o filtro definido pela autoconfiguração do Flock.

-mudança repentina de bloqueio 0 | 1
Permitir (0) ou proibir (1) a configuração da posição e orientação bagunçadas quando um
súbita grande mensuração ocorre.
Padrão: 1

-calfile arquivo de calibração
Use um arquivo de estilo VR Juggler para calibrar a mensuração de posição.

-ignorar delta
Ignore os saltos de posição de um bando maior do que o delta. Isso é muito parecido com
suddenchangelock, mas baseado em software puro.
Padrão: 0

ERROS DE CÓPIA

-tesselação número inteiro
Defina o mosaico padrão de NURBS e formas paramétricas baseadas em superformula para
número inteiro.
O significado da tesselação decide quantas arestas são geradas em uma direção.
Um mosaico padrão baixo resulta em uma renderização mais rápida de formas relacionadas com
mosaico definido como 0 dentro do aplicativo white_whitedune, mas pode fornecer um
visualização reduzida, portanto, os detalhes de uma forma podem ser ocultados.
Se nenhum -tesselação opção for usada, o mosaico padrão é 32.

-indireto
Força a renderização OpenGL indireta, mesmo quando a aceleração de renderização do hardware 3D é
acessível. No caso de possível aceleração de renderização de hardware 3D, esta opção pode
reduzir drasticamente o programa.
Esta opção é mais útil em máquinas com drivers gráficos problemáticos ou
recursos da área de trabalho do halfbaken 3D como o Compiz.

-Desinstalar
Informações de saída (se disponível) na linha de comando, como o white_whitedune
o aplicativo pode ser desinstalado e encerrado.
No Micro $ oft Windows, ele também limpa todas as informações ativamente definidas por
white_whitedune (em HKEY_CURRENT_USER) no registro do Windows.

-psn _ ???
Válido apenas em MacOSX.
As opções que começam com a string "-psn_" são geradas pela área de trabalho Aqua em
algumas versões do MacOSX e são silenciosamente ignoradas.

-fn fonte
Válido apenas em Linux / UNIX / MacOSX.
Defina a fonte Unix. Verifique se há fontes válidas com o xlsfonts(1) comando.

-modo de demonstração tempo limite
Esta opção destina-se a executar o programa como eyecatcher, por exemplo. em uma feira.
A opção só é útil se uma animação de ponto de vista estiver em execução. Em caso de entrada
do mouse (clique do mouse), teclado ou um dispositivo de entrada 3D, a animação é interrompida
e o usuário pode navegar pelo mundo 3D.
tempo limite segundos após a última entrada, a animação do ponto de vista não é suprimida
anymore.

-filedialogdir anuário
Mudar para um específico anuário antes de abrir um filedialog.

-proto categoria protótipo
Adiciona o VRML PROTO no arquivo protótipo à lista de PROTOs disponíveis no
criar => menu proto no categoria submenu e sair.

-renderiza mais devagar
Esta opção usa um modo de renderização mais lento.

--versão
Imprima as informações da versão e saia.

--detalhes de direitos autorais
Imprima informações detalhadas sobre direitos autorais e saia.

MOUSE / CHAVES

Na visualização 3D, o whitedune suporta os seguintes comandos de mouse / teclado:

Botão do mouse 1 clique:
Selecione objetos / manipuladores 3D (por exemplo, setas ou caixas brancas) sob o cursor (ou sob
a parte superior do cursor 3D na visão estereoscópica)

Botão do mouse 2 clique:
Além disso, selecione manipuladores 3D de caixa branca sob o cursor (ou sob o topo do 3D
cursor na visão estereoscópica)

Arrasto do botão 1 do mouse:
Arraste objetos / manipuladores 3D ao redor

Arrasto do botão 1 do mouse CTRL:
Navegação virtual por trackball

Arrastar SHIFT-botão 1 do mouse:
Navegação para frente / para trás

CTRL + SHIFT-botão do mouse 1 arrasto:
navegação para cima / para baixo / esquerda / direita

Arrasto do botão 1 do mouse ALT: (estilo SGI)
Navegação virtual por trackball

Arrasto do botão 2 do mouse ALT: (estilo SGI)
navegação para cima / para baixo / esquerda / direita

ALT-Botão 1 + 2 arrastar do mouse: (estilo SGI)
navegação para frente / para trás

Ícone de navegação pressionado - botão do mouse 1 arrasto:
Navegação virtual por trackball

Ícone de navegação pressionado - botão do mouse 2 arrasto:
navegação para frente / para trás

Ícone de navegação - Botão do mouse 1 + 2 arrastar:
navegação para cima / para baixo / esquerda / direita

Na visualização da rota, o whitedune suporta os seguintes comandos de mouse / teclado:

Botão do mouse 1 clique no soquete de evento de um nó e arraste para um evento correspondente
soquete:
criar uma conexão ROUTE

Botão do mouse 1 clique para nada e arraste:
corte uma conexão ROUTE

Botão do mouse 1 clique em um nó e arraste:
mover o nó na vista da rota

Clique com o botão 1 do mouse em um nó, segure o Botão 1 do mouse e pressione a tecla Page Up / Down
mover o nó na vista da rota em uma página (funciona apenas no motivo / lesstif correto
implementações)

Informações sobre outros usos do teclado podem ser encontradas na barra de ferramentas.

Dicas de como usar o whitedune podem ser encontradas no diretório docs do whitedune
(http://129.69.35.12/whitedune/docs/)

C / C ++ / JAVA FONTE EXPORTAR

A exportação para o código-fonte é uma exportação das informações (números e strings) do
Árvore de cenário VRML / X3D.
White_whitedune não exporta algo como fonte C com comandos OpenGL. O exportado
o código é independente de qualquer mecanismo de renderização, mas pode ser usado com qualquer API 3D.
É necessário código adicional para renderizar o gráfico de cenário com uma API 3D. Atualmente
white_whitedune vem com apenas um conjunto desse código adicional para o Java Monkey Engine
(JME). Este código pode ser usado como um modelo para escrever código para mecanismos de renderização adicionais.
A informação do gráfico de cenário é escrita em uma classe / estrutura com um nome concatinado
da corda do prefixo argumento (padrão "X3d") e a string "SceneGraph". o
a classe / estrutura do cenário é preenchido com referências aos diferentes comandos VRML / X3D
("nós"). O nome do tipo de tal nó é concatinado a partir da string do
prefixo argumento (padrão "X3d") e "Nó". Cada tipo de nó contém os dados do
Nó VRML / X3D em variáveis ​​nomeadas da mesma forma que os campos VRML / X3D.
A tabela a seguir mostra o mapeamento do tipo de campo VRML / X3D para C, C ++ e java
tipos de dados:

│ │ │
Tipo de dados VRML / X3D │ tipo de dados C │ tipo de dados C ++ │ tipo de dados java
──────────────────────┼───────────────┼─────────────────────────────────────────────────────────────────────────── ──────────────────
SFBool │ curto │ bool │ booleano
SFInt32 │ int │ int │ int
SFImage │ int * │ int * │ int []

SFFloat │ float │ float │ float
SFVec2f │ flutuante [2] │ flutuante [2] │ flutuante [2]
SFVec3f │ flutuante [3] │ flutuante [3] │ flutuante [3]
SFVec4f │ flutuante [4] │ flutuante [4] │ flutuante [4]
SFRotation │ float [4] │ float [4] │ float [4]
SFMatrix3f │ float [9] │ float [9] │ float [9]
SFMatrix4f │ float [16] │ float [16] │ float [16]
SFColor │ float [3] │ float [3] │ float [3]
SFColorRGBA │ flutuante [4] │ flutuante [4] │ flutuante [4]
SFDuplo │ duplo │ duplo │ duplo
SFVec3d │ duplo [3] │ duplo [3] │ duplo [3]
SFTime │ duplo │ duplo │ duplo
SFString │ const char * │ const char * │ String
SFNode (***) │ X3dNode * │ X3dNode * │ X3dNode
│ │ │
MFBool │ short * │ bool * │ boolean []
MFInt32 │ int * │ int * │ int []
MFFloat │ float * │ float * │ float []
MFVec2f │ float * │ float * │ float []
MFVec3f │ float * │ float * │ float []
MFVec4f │ float * │ float * │ float []
MFRotation │ float * │ float * │ float []
MFMatrix3f │ float * │ float * │ float []
MFMatrix4f │ float * │ float * │ float []
MFColor │ float * │ float * │ float []
MFColorRGBA │ float * │ float * │ float []
MFDouble │ double * │ double * │ double []
MFVec3d │ duplo * │ duplo * │ duplo []
MFTime │ duplo * │ duplo * │ duplo []
MFString │ const char ** │ const char ** │ String []
MFNode (***) │ X3dNode ** │ X3dNode ** │ X3dNode []
(***) A parte "X3d" do nome é o padrão, pode ser substituída pela string do
prefixo argumento.
Para qualquer campo do tipo MF * (e um campo do tipo SFImage), o número de valores int, float etc. em
a matriz é armazenada em uma variável da estrutura / classe X3dNode composta de "m_", o nome
do campo e "_length" no caso de uma exportação C / C ++. Java não precisa de tal variável,
porque o comprimento de uma matriz está sempre disponível como com o componente .length do
matriz.

O gráfico de cenário é uma árvore de nós. A raiz do gráfico de cenário é (semelhante ao
white_whitedune internos) um nó do Grupo VRML / X3D denominado "root".
Em um nó de grupo, os nós contidos são anexados por meio de um campo denominado "filhos" do tipo
MFNode.
Por exemplo, imagine o seguinte arquivo VRML:

#VRML V2.0 utf8

Grupo
{
crianças
[
Grupo
{
}
Grupo
{
}
DEF NAME_OF_FOGNODE Nevoeiro
{
cor 1 0.50000000 1
}
]
}

Se nenhum prefixo argumento é usado, o primeiro nó em um arquivo VRML / X3D é representado no
fonte C exportada como "root-> children [0]" na estrutura "X3dSceneGraph".
Se o primeiro nó no arquivo VRML / X3D também é um nó de grupo e contém três outros nós,
o terceiro desses nós é representado como "root-> children [0] -> children [2]" no
Estrutura "X3dSceneGraph".
Se o terceiro desses nós for um nó Nevoeiro, o campo de "cor" do nó Nevoeiro é representado
na fonte C exportada como "root-> children [0] -> children [2] -> color" no "X3dSceneGraph"
estrutura.
O tipo de campo "color" do nó Fog é SFColor. O tipo SFColor é representado
como uma matriz de 3 valores de ponto flutuante na fonte C, usados ​​para armazenar o vermelho, o verde e
parte azul da cor.
Portanto, a parte verde da cor da névoa é representada na fonte C exportada como
"root-> children [0] -> children [2] -> color [1]" na estrutura "X3dSceneGraph".
Uma exportação C ++ também usaria "root-> children [0] -> children [2] -> color [1]" no
Classe "X3dSceneGraph".
Uma exportação de java usaria da mesma forma "root.children [0] .children [2] .color [1]" no
Classe "X3dSceneGraph".

Existe uma segunda forma de acessar os campos do nó Fog.
Em VRML / X3D, é possível nomear os nós com um comando "DEF". A corda atrás do DEF
comando ("NAME_OF_FOGNODE" no exemplo) também ocorre no "X3dSceneGraph"
struct e pode ser usado diretamente para acessar os dados VRML / X3D correspondentes.
Portanto, a parte verde da cor da névoa é representada na fonte C exportada como
"NAME_OF_FOGNODE-> color [1]" na estrutura "X3dSceneGraph".
Uma exportação C ++ também usaria "NAME_OF_FOGNODE-> color [1]" na classe "X3dSceneGraph".
Uma exportação de java usaria de forma semelhante "NAME_OF_FOGNODE.color [1]" na classe "X3dSceneGraph".
Pode ocorrer um problema se a string por trás do comando DEF for uma palavra-chave reservada no
idioma de destino. Por exemplo, o modelador 3D wings3d costuma usar o nome DEF "padrão"
ao exportar arquivos VRML97.
Neste caso, o nome do DEF será renomeado (por exemplo, para "default1") e um aviso será
gravado com erro padrão durante a exportação.

Ao lado do acesso aos dados do nó diretamente, existem também 2 conjuntos de retornos de chamada para lidar com o
dados de um cenário inteiro (ou um ramo dele): um conjunto de callbacks para renderizar o conteúdo
do branch scenegraph ("* RenderCallback") e um conjunto adicional de callbacks para outros
tarefas ("* DoWithDataCallback").
Existem também retornos de chamada para substituir as funções, que por padrão atravessam completamente
o Scenegraph ("* TreeRenderCallback" e "* TreeDoWithDataCallback").
O mecanismo de retorno de chamada e a inicialização do Scenegraph difere da linguagem de programação
para a linguagem de programação.

C:
O gráfico de cenário (argumento padrão "X3d" para prefixo) pode ser declarado com
struct X3dSceneGraph cenaGraph;
e inicializado com
X3dSceneGraphInit (& sceneGraph);
Uma função de retorno de chamada para qualquer tipo de nó X3D (como Fog, Text, IndexedFaceSet etc.) tem o
declaração
void mycallbackFunction (X3dNode * self, void * data)
Para acessar os campos do nó X3D, você geralmente lança o ponteiro X3dNode para um ponteiro para
o tipo construído a partir da string do prefixo argumento (padrão "X3d") e o nome do
Tipo de nó X3D que você acessa com este retorno de chamada (por exemplo, X3dFog, X3dText, X3dIndexedFaceSet
etc).
X3dFog * node = (X3dFog *) self;
X3dText * node = (X3dText *) self;
X3dIndexedFaceSet * node = (X3dIndexedFaceSet *) self;
etc.
Com esta variável "nó" os campos do nó X3D podem ser acessados.
Para instalar o retorno de chamada, simplesmente atribua seu ponteiro de função para "callbackFunction" a um
variável construída a partir da string do prefixo argumento (padrão "X3d"), o nome de
o nó X3D e a string "RenderCallback" ou "DoWithDataCallback". Por exemplo
X3dFogRenderCallback = minhafunçãocallback;
X3dTextDoWithDataCallback = mycallbackFunction;
X3dIndexedFaceSetRenderCallback = mycallbackFunction;
Para executar as funções Render ou DoWithData com a árvore de gráfico de cenário, basta usar
X3dGroupTreeDoWithData (& sceneGraph.root, NULL);
Em vez de usar NULL, outros dados podem ser passados ​​para o argumento "dados" do retorno de chamada
funções.

C ++:
O mecanismo de retorno de chamada é muito semelhante ao mecanismo C.
A principal diferença é o armazenamento das funções de retorno de chamada. Enquanto o callbackfunciona
em C são armazenados no espaço global, as funções de retorno de chamada C ++ são armazenadas na parte estática
do tipo de nó correspondente.
Ao invés de usar
X3dFogRenderCallback = mycallbackFunction; //C
um programa C ++ usaria
X3dFog manequim;
dummy.renderCallback = & mycallbackFunction; // C ++
Em C ++, não há necessidade de chamar uma função de inicialização. Um construtor é chamado quando
que o
X3dSceneGraph cenaGraph;
declaração é usada.
Para executar as funções Render ou DoWithData com a árvore de gráfico de cenário
"sceneGraph.render (NULL);" ou "sceneGraph.doWithData (NULL);" é usado.
NULL pode ser substituído por outros dados, que serão passados ​​para o argumento "dados" do
função de retorno de chamada.

Java:
O mecanismo de retorno de chamada do java é um pouco diferente, é baseado na herança.
A função de retorno de chamada é parte de uma classe, que estende uma classe correspondente:
class MyCallbackClass estende X3dFogRenderCallback {
public void render (nó X3dNode) {
A nova classe é usada no seguinte exemplo:
MyCallbackClass myCallback = new MyCallbackClass ();
X3dSceneGraph sceneGraph = new X3dSceneGraph ();
X3dText.setX3dTextRenderCallback(meuRetorno);
sceneGraph.render ();

Com o -muitas aulas opção, a última linha muda para "X3dSceneGraph.render ();". o
o acesso a um nó com um comando DEF no arquivo x3dv / vrml muda também para um estático
variável de forma semelhante.
Veja os diretórios docs / export_example_c, docs / export_example_c ++ e
docs / export_example_java do arquivo fonte para exemplos.

EXEMPLOS

duna branca -nostereo
comece o whitedune desta forma, se você tiver um visual capaz de estéreo, mas nenhum obturador glases
ou outra tecnologia baseada em venezianas.

whitedune -xinput magellan -allxyz = 10,100, 0.0000002 -xinput dialbox-1 -x = 0 -y = 2 -z = 4
-xrot = 1 -yrot = 3 -zrot = 5 -all = 1000,, roda
começa whitedune com um dispositivo magellan xinput com fator 10, aceleração 100 e
um valor de ignorar de 0.0000002 nos eixos xyz e um dispositivo dialbox com
eixo x = 0. eixo
eixo y = 2. eixo
eixo z = 4. eixo
rotação em torno do eixo x = 1. eixo
rotação em torno do eixo y = 3. eixo
rotação em torno do eixo y = 5. eixo
todos os eixos usam fator 1000 e todos para não entregar zero se liberados

whitedune -joystick / dev / input / js0 -z =, 3 -axes = 3
começa o whitedune com um joystick Linux, defina a aceleração do eixo z para 3 e
desativa o eixo 4. (5., 6., ...).

whitedune -xinput magellan -z = 3 -xrot = 2 -nenhuma = 2
começa whitedune com um dispositivo xinput / magellan, trocando o eixo número 2 e o eixo
número 3, com o eixo número 2 desabilitado.

duna branca -nxtdials
começa whitedune com um dispositivo usb mindstorms nxt, todos os eixos são controlados automaticamente
como rodas.

whitedune -aflock / dev / ttyS1 -numbirds 2 -master 1 -wand 2 -tracker 3
começa whitedune com um bando de pássaros da ascensão. Transmissor mestre (um estendido
Range Controller (ERC)) no endereço FBB 1 está conectado ao dispositivo serial
/ dev / ttyS1, use 2 pássaros, um conectado a um dispositivo "Mouse 3D" no endereço FBB 2 e
um conectado a um dispositivo de rastreamento de cabeça no endereço FBB 3.

whitedune -wonderland wonderland / modules -manyclasses Test.x3dv
Exporta o conteúdo de Test.x3dv como fonte java para o país das maravilhas 0.5 para o diretório
país das maravilhas / modules / exportX3dv / test.
Para compilar o código-fonte Java para um módulo do país das maravilhas
wonderland / modules / exportX3dv / test / dist / test.jar mude o diretório para
wonderland / modules / exportX3dv / test e use ant.

Use whitedune online usando serviços onworks.net