Un concepto que no acabo de entender vértices y polígonos

[Dexter]

Esto debe ser de básica, pero es que, no lo tengo muy claro aun, pongo un ejemplo:






Lo que en 3dsmax son vértices en ZBrush son points, sin embargo, el max me marca como polígonos el doble.

Por ejemplo, en la última imagen ¿la malla tiene un millón y medio de polígonos o tres millones? A ver si alguien me lo puede aclarar.

-- IMÁGENES ADJUNTAS --

[Caronte]

Te cuenta cada Quad como dos tri, por eso muestra el doble de polígonos.

[Dexter]

Gracias Caronte. Es verdad, creo que es por los modificadores TurboSmooth y displace, he probado a colapsarlo y convertirlo de nuevo a Editable Poly y coinciden en 1.500.000 vértices y poly. ¿quiere decir esto que el modelo colapsado pesaria menos que con los modificadores? ¿sin colapsar estaría renderizando y moviendo en el viewport un modelo de 3 millones?

[Fiz3d]

No, es una simple cuenta, cada polígono cuadrado esta formado por dos triángulos, internamente los viewports trabajan en (Faces) triángulos, y el render también, es más, si te fijas en la información que te da el max cuando hace render, bien de triángulos no de polígonos. Saludos.

[Dexter]

Gracias Fiz3d, el caso es que, ahora que lo dices recuerdo haber leído o estudiado algo de eso, el día que me explicaron esto debía estar pensando en otra cosa.

Lo que me queda por saber es si consumiria más recursos o si pesaria más (en render y viewport), una malla con TurboSmooth y displace o la misma malla colapsada a un Editable Poly. ¿sabéis que es exactamente lo que hace el displace?
De todos modos, seguiré experimentando.

[Caronte]

La diferencia si la hay será prácticamente inapreciable.

[Fiz3d]

Creo que el TurboSmooth es más rápido que el MeshSmooth, por lo tanto supongo que, el TurboSmooth es más rápido que colapsar la malla, de todos modos esas cosas son fáciles de comprobar, ahora en render ni idea, yo es que zoy de videojuegoz y a mi 2 millones de polígonos me tienen que ir a unos 40 frames por segundo por segundo.

El tema de ser triángulos es simple, el triángulo es la figura geométrica más simple que hay, por lo tanto si se trata de optimizar, un ordenador lo trasformara todo a triángulos. Saludos.

[Dexter]

Mh, ya voy entendiendo. Muchas gracias Caronte & Fiz3d.

[TBC3D]

Hola, no sé cómo va el partido, pero partamos de la base, de que hay polígono a partir de tres puntos y no cuatro. Luego un cuadrado es un polígono, pero de cuatro lados. Puede haber polígonos de varios lados, solo que casi nunca los usamos porque se fastidiaría la malla.

En cambio sí podemos usar uno de cuatro, la mayoría de los programas 3d pintan un cuadrado, cuando en realidad están pintando dos triángulos juntos.

Que no muestre todas las aristas, no quiere decir que no estén, dado que el cálculo matemático que hace el software, sería imposible si no forma polígono, y eso se hace, como dije, a partir de tres nodos. Saludos.

[promineo]

Lo que me queda por saber es si consumiria más recursos o si pesaria más (en render y viewport), una malla con TurboSmooth y displace o la misma malla colapsada a un Editable Poly. ¿sabéis que es exactamente lo que hace el displace?
De todos modos, seguiré experimentando.

Una malla en edit Mesh colapsado y sin suavizado es lo más rápido. Con el stak limpio.

Edit poly con displace y mesmooth la opción más lenta.

El displace hasta dónde yo sé.toma como referencia una imagen sea cual sea, y toma sus valores de grises, por lo que se suele usar imágenes en blanco y negro. Lo que hace el displace es dar un valor a un eje determinado (por ejemplo, z) un valor que equivale a la fuerza con que el vértice tenga más o menos valor(posición en z), para ello se usa las escalas de grises, tanto es así que, negro seria fuerza 0% y blanco 100% de fuerza.

Pero si buscas optimización en viewport y render lo suyo es usar normal mapping o Relief mapping.

[Fiz3d]

Tanto es así que, negro seria fuerza 0% y blanco 100% de fuerza.

En algunos casos la cosa se complica un poco más, el problema del displace es simple, una imagen a escala de grises solo tiene 8 bit por canal, como solamente hay un canal pues se queda con los 8 cutre bits, con esto solo hacemos 256 niveles de grises, que claro está, todo dios dirá, vaya es suficiente para que quieres más, en un paisaje, por ejemplo, eso se te queda en nada, imagínate un paisaje con sus lagos, sus rios, y su pedazo de montaña de 2 km de altura, a esto le añadimos que hay un mar que está a cota -100 metros, pues tendremos una definición de un píxel de mapa de displace (en altura) para cada casi 8pregunta de montaña, vamos que para un videojuego de los años 90 podría valer, por suerte podemos hacer mapas de 16 bit en escala de grises, dan mil problemas, pero tenemos la friolera de 68.000 niveles de gris, eso sí que es definición en un displace y lo demás tonterías.

El funcionamiento pues como dice Promineo, no sé si solo pasa en videojuegos, pero muchas veces se toma el valor 128 (en 8 bit) para señalar el punto medio, por así decirlo la cota 0, en muchos casos y para ahorrar definición, ese valor de cota 0 se puede variar manualmente, depende mucho de lo que quieras desplazar, aunque esto es más para Paralláx Maping, que es como el displace, pero a nivel de píxeles, o sea, geométricamente no toca la malla solo altera el mapeado, creo que hay más de una forma de hacer displace, cada motor de render tiene sus propios métodos para hacerlo. Saludos.

[Mars Attacks]

No tantos, sólo 65536.

[Dexter]

En realidad, son 4 millones y pico de niveles de intensidad, los mapas exportados desde ZBrush usando Displacement Exporter pueden ser tifs de hasta 32 bit (floating point que dicen). Gracias Promineo y cia, eso más o menos lo comprendía o por lo menos lo he recordado al leeros, (algo tuve que aprender en el máster).

Lo que yo me preguntaba es por la utilidad o ventajas del método del desplazamiento. Aparte de las obvias: poder jugar con la relación detalle:subdivisión y trabajar en 3dsmax con una malla de tropecientos mil polígonos sin tener que cargar un (*.obj) de tropecientos mil polígonos.

En principio ¿no sería lo mismo la malla original de 1.5 millones, exportada tal cual, que una malla subida a 1.5 millones por medio de TurboSmooth y deformada con displace? ¿o de alguna manera los modificadores aligeran el trabajo en renders o viewports?
La verdad es que debería hacer la prueba yo mismo, pero no se me ocurre un modo objetivo (solo a ojo) de comprobar la performance, y eso suponiendo que el max no se pete al intentar importar un (*.obj) demasiado gordo.

[TBC3D]

Max soporta hasta cierta cantidad de polígonos. Yo estoy modelando un objeto que me habían pasado en Nurbs, que venía de Solidworks, imposible de mover en 3dsmax.

[Dexter]

Ya lo había notado ya, de todos modos yo casi nunca paso del millón y medio.

[promineo]

Vaya una manera de comprobar performance bastante sencilla tanto render como en viewport. Normalmente no podemos comparar si es más rápido un objeto con MeshSmooth o TurboSmooth (por ejemplo) cuando el modelo tiene pocos polígonos.

Una manera fácil es hacer multitud de copias en la escena y animarlas y ver que frame rate te da o calcular el tiempo de render en el otro caso.

[Dexter]

Bueno Promineo, por polígonos no será, cada modelo tiene entre uno y tres millones. Me fijare en las frames por segundo como dices y en los tiempos de render.

[Fiz3d]

Anda no salió mi mensaje, era largo con ganas, y algo aburrido. Gracias por la aclaración Mars, por eso puse la friolera, Dexter, lo de 32 bit, ¿es por canal? Me sorprendería una imagen con 128 bit, que no sean canales especiales como z, o id de objeto. Saludos.

[Caronte]

Anda no salió mi mensaje, era largo con ganas, y algo aburrido. Gracias por la aclaración Mars, por eso puse la friolera, Dexter, lo de 32 bit, ¿es por canal? Me sorprendería una imagen con 128 bit, que no sean canales especiales como z, o id de objeto. Saludos.

Debe ser un solo canal de 32bits. No tiene sentido exportar nada más, si solo es un mapa de desplazamiento.

[Dexter]

Pues, así lo entendí yo, aunque puedo equivocarme claro. He estado repasando la wiki del Displacement Exporter y dice algo tal que así:
channel resolution.

Each channel has an associated resolution, which is a Measure of how Many gradations of intensity it can represent. The higher the resolution, the more accurately visual información can be estored. For example, Many image file formats allow only 256 intensity levels for each color channel. Such a format can represent only 256 intensities of pure red (the blue and green channels Will be 0 if a pure red is being shown), which is usually enough todo produce decent onscren images, but is far less than the range perceptible by the human eye. If you se phrases such as channel width, bit depth, channel format, and the like, chances are they are all referring todo properties afecting channel resolution.

The resolution of a channel is determined by how much data is estored, for each image píxel, in that channel, and this is normally expressed by the number of bits (binary digits) estored at each point. Heres a summary of how the number of bits corresponds todo the resolution of a channel:
Bits -intensity levels.
8 bits - 256.
16 bits - 65,536.
32 bits - 4,294,967,296.

Other things being equal, the greater the resolution of the channel the better.
32 bit formats are usually estored in what is called a floating-point format. In practical terms, this allows a further degre of accuracy under most circumstances.
[.].

In addition, each channel in a tif file may be 8 bits, 16 bits, or 32 bits..

Estas cuestiones tan técnicas y en inglés, igual lo interprete mal, no sé. ¿cómo lo veis?

[Dexter]

Texporter. El enlace, por si he omitido algo importante al editarlo.